From tpassin at idsonline.com  Mon Nov  1 02:54:21 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:16:23 2004
Subject: Undeclared namespace
References: <A26F84C9D8EDD111A102006097C4CD0D0E9024@sohos002.ied-support.net>
Message-ID: <007601bf2414$c5bce4e0$4515b0cf@tomshp>


From: Mark Birbeck <Mark.Birbeck@iedigital.net>

> Thomas B. Passin wrote:
> > My version of IE5 does not need to have the namespace
> > declared as a #FIXED attribute
>
> Please send me a copy of it, or tell me where you downloaded it from.
>
> Just joking, but I disagree, Thomas. This was discussed a while back in
> relation to XHTML, when I seriously fell out of love with Microsoft.

Probably before I joined the list.

Just to be complete even though you said you were joking, I just rechecked
using my copy of IE5.  The XML with DTD works even though there is no
namespace attribute declared in the DTD.  My exact version of IE5 is

    5.00.2614.3500, 128 bit

    update versions q231452, q231450

The actual xml document I tested is the following, based on Anand Raman's
original mailing:

=========================================================================
DOCTYPE experience[
<!ELEMENT experience (project+)>
<!ELEMENT project
(title,employer?,client?,duration?,team?,position?,description?,contribution
?)>
]>

<experience xmlns:exp="http://www.angelfire.com/ar/diduknow/experience">
 <project>
   <exp:title>Management Information Systems</exp:title>
   <employer>Infotech ESD</employer>
   <client>Finance Department</client>
   <exp:duration>till date</exp:duration>
  </project>
</experience>
==========================================================================

When I say that "it works", I mean that IE5 displays the document text and
does not give any error messages.

> If you convert HTML to nice neat XHTML and then try to use a reference
> to the DTDs supplied by W3C you get errors. The W3C DTDs do not define
> the namespace attribute as fixed, and MS in their wisdom have said you
> must. No-one has explained why, and there is little justification for

The W3C namespace recommendation does say that if you use a DTD you have to
declare the namespace.  It also says that the namespace declaration can be
established by the default value for the (namespace) attribute.  This
implies that you may optionally declare its value in the DTD (#FIXED would
also be optional), and then you would not have to specify the namespace when
you actually write an element.  But my version of IE5 insists on needing the
namespace declaration in the element event if the DTD declares it as #FIXED!
Also, the Recommendation says that element and attribute name declared in
the DTD must be qualified.  Again, my copy of IE5 differs, since it would
not allow the qualification in the DTD.

Christopher R. Maden is right when he said that the above example for IE5
would not validate against the Recommendations, but it does work with my
IE5.

So I don't bother using IE5's xml or xsl capabilities.  It's not worth it
even for use as a learning tool, you have to unlearn too much.

> it, so the only solution is to remove the DTD reference - and of course
> you no longer technically have valid XHTML!!!!!!
>
> Damn. I was doing so well. My therapist is going to be very
> disappointed.
>
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From shawn at activated.com  Mon Nov  1 06:04:04 1999
From: shawn at activated.com (Shawn Silverman)
Date: Mon Jun  7 17:16:23 2004
Subject: Entities and non-validation
Message-ID: <381D2D46.4CBE7A4B@activated.com>

Hi, all.

How should non-validating parsers handle undeclared:

	1) Parameter entities in the DTD
	2) General entities in the DTD
	3) General entities in the document

I like to qualify my question by stating that it is assumed that all of
these entities are used appropriately, ie. PE's only in the DTD, GE's
inside attribute values and content, etc.

I am under the impression that if standalone='no' for the document that
a non-validating parser can assume that all undeclared entities are
external.  Is this correct?

My second question is similar, and comes from section 4.4.3, "Included
If Validating".

The first paragraph states that:

"When an XML processor recognizes a reference to a parsed entity, in
order to validate the document, the processor must include its
replacement text. If the entity is external, and the processor is not
attempting to validate the XML document, the processor may, but need
not, include the entity's replacement text. If a non-validating parser
does not include the replacement text, it must inform the application
that it recognized, but did not read, the entity."

	1) Obviously, the parser can tell if the entity is external if it has
previously been declared.  But what if it has't?  What should a
non-validating parser do?
	2) How does the parser "inform the application" via the SAX interface? 
Is this through the EntityResolver interface?

Thanks,
	-Shawn

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



From sunker at telkom.net  Mon Nov  1 09:03:07 1999
From: sunker at telkom.net (sunker@telkom.net)
Date: Mon Jun  7 17:16:24 2004
Subject: DOM Transform ?
Message-ID: <61D3A6AB14FED211856500001C055D9633E01E@FS01>

Hi, All

I've some problem with Dom
(xml-f.TransfrormNodeToObject('xsl-f.xsl',Response)), When i include the DTD
or schema the xsl file couldnot parse the xml & xsl to HTML format. but when
i redirect from xml, the xsl work done, such as :

xml-f.xml
================
<?xml version='1.0'?>
<!DOCTYPE [
<!ENTITY tst "Test it">
]>
<?xml-stylesheet type="text/xsl" href="xsl-f.xsl"?>
<test>
  <testing>hello</testing>
  <testing>Pale</testing>
    <testing>&tst;</testing>
</test>

xsl-f.xsl
================
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"
xmlns="http://www.w3.org/TR/REC-html40" result-ns="layout">
   <xsl:template match="/">
      <HTML>
         <HEAD>
            <TITLE>Test</TITLE>
         </HEAD>
         <BODY>
           <xsl:apply-templates select="//testing"/>
         </BODY>
      </HTML>
   </xsl:template>
   <xsl:template match="testing">
        <xsl:value-of/>
        <BR/>
   </xsl:template>
</xsl:stylesheet>

---------
Please Help me with the DOM, Parsing XML + XSL -----> HTML (pure, using
Jscript)...

thanks,
http://www.geocities.com/researchtriangle/campus/7211
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2640 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991101/876db664/winmail.bin
From anandram at wipsys.soft.net  Mon Nov  1 09:27:04 1999
From: anandram at wipsys.soft.net (Anand Raman)
Date: Mon Jun  7 17:16:24 2004
Subject: Undeclared namespace
References: <A26F84C9D8EDD111A102006097C4CD0D0E9024@sohos002.ied-support.net> <007601bf2414$c5bce4e0$4515b0cf@tomshp>
Message-ID: <381D5B87.59381859@wipsys.soft.net>

Hi guys
Sorry to have been out of this discussion for some time , but i we were having holidays here
..
Thomas the code which u wrote works in my IE too. But that was not my problem .. I had
duplicate elements in the DTD and i was trying to use namespaces to overcome this. However IE
required a explicit namespace attribute definition in the DTD wherever i used exp: .Anyway the
problem was solved after incoporatiing this.

I am attaching the relevant portions of the xml and DTD file here .
The problem was occuring when i had not used line number 8 and 12 respectively in the DTD ..
After incorporating these lines IE 5 is displaying the XML file

Thanx a lot for all the help
Bye
Anand Raman


"Thomas B. Passin" wrote:

> From: Mark Birbeck <Mark.Birbeck@iedigital.net>
>
> > Thomas B. Passin wrote:
> > > My version of IE5 does not need to have the namespace
> > > declared as a #FIXED attribute
> >
> > Please send me a copy of it, or tell me where you downloaded it from.
> >
> > Just joking, but I disagree, Thomas. This was discussed a while back in
> > relation to XHTML, when I seriously fell out of love with Microsoft.
>
> Probably before I joined the list.
>
> Just to be complete even though you said you were joking, I just rechecked
> using my copy of IE5.  The XML with DTD works even though there is no
> namespace attribute declared in the DTD.  My exact version of IE5 is
>
>     5.00.2614.3500, 128 bit
>
>     update versions q231452, q231450
>
> The actual xml document I tested is the following, based on Anand Raman's
> original mailing:
>
> =========================================================================
> DOCTYPE experience[
> <!ELEMENT experience (project+)>
> <!ELEMENT project
> (title,employer?,client?,duration?,team?,position?,description?,contribution
> ?)>
> ]>
>
> <experience xmlns:exp="http://www.angelfire.com/ar/diduknow/experience">
>  <project>
>    <exp:title>Management Information Systems</exp:title>
>    <employer>Infotech ESD</employer>
>    <client>Finance Department</client>
>    <exp:duration>till date</exp:duration>
>   </project>
> </experience>
> ==========================================================================
>
> When I say that "it works", I mean that IE5 displays the document text and
> does not give any error messages.
>
> > If you convert HTML to nice neat XHTML and then try to use a reference
> > to the DTDs supplied by W3C you get errors. The W3C DTDs do not define
> > the namespace attribute as fixed, and MS in their wisdom have said you
> > must. No-one has explained why, and there is little justification for
>
> The W3C namespace recommendation does say that if you use a DTD you have to
> declare the namespace.  It also says that the namespace declaration can be
> established by the default value for the (namespace) attribute.  This
> implies that you may optionally declare its value in the DTD (#FIXED would
> also be optional), and then you would not have to specify the namespace when
> you actually write an element.  But my version of IE5 insists on needing the
> namespace declaration in the element event if the DTD declares it as #FIXED!
> Also, the Recommendation says that element and attribute name declared in
> the DTD must be qualified.  Again, my copy of IE5 differs, since it would
> not allow the qualification in the DTD.
>
> Christopher R. Maden is right when he said that the above example for IE5
> would not validate against the Recommendations, but it does work with my
> IE5.
>
> So I don't bother using IE5's xml or xsl capabilities.  It's not worth it
> even for use as a learning tool, you have to unlearn too much.
>
> > it, so the only solution is to remove the DTD reference - and of course
> > you no longer technically have valid XHTML!!!!!!
> >
> > Damn. I was doing so well. My therapist is going to be very
> > disappointed.
> >
> > 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtdfile.dtd
Type: text/dtd
Size: 1269 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991101/7997339d/dtdfile.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmlfile.xml
Type: text/xml
Size: 1271 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991101/7997339d/xmlfile.xml
From mparul at in.ibm.com  Mon Nov  1 09:50:39 1999
From: mparul at in.ibm.com (mparul@in.ibm.com)
Date: Mon Jun  7 17:16:24 2004
Subject: AND, OR, XOR Operators DTD
Message-ID: <CA25681C.003603C8.00@d73mta05.au.ibm.com>

Hi,

Is there a DTD defined for using AND, OR, XOR, NOT operators that one can
use
straight away to define logical expressions !

Thanks
Parul



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



From mparul at in.ibm.com  Mon Nov  1 09:52:31 1999
From: mparul at in.ibm.com (mparul@in.ibm.com)
Date: Mon Jun  7 17:16:24 2004
Subject: Referencing multiple DTD in an XML document
Message-ID: <CA25681C.00360FB8.00@d73mta05.au.ibm.com>


Hi,

Is it possible to reference two DTD files in the DOCTYPE declaration in an
XML document?
If not, then how can one use both MathML and say SpeechML tags in an XML
document.

Thanks in advance
Parul





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



From mparul at in.ibm.com  Mon Nov  1 10:50:48 1999
From: mparul at in.ibm.com (mparul@in.ibm.com)
Date: Mon Jun  7 17:16:24 2004
Subject: Any DTD for DATE, URL, PRICE ??
Message-ID: <CA25681C.003B76E9.00@d73mta05.au.ibm.com>


Hi,

Is there any existing DTD for common fields like DATE, AMOUNT, PRICE, URL,
ADDRESS etc??

Thanks in advance
Parul



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



From matthew at praxis.cz  Mon Nov  1 11:32:41 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:24 2004
Subject: A Plea for Schemas
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de> <199910291614.MAA27642@westnet.com>
Message-ID: <381D7A24.393CABBE@praxis.cz>

I totally agree. The idea of some kind of discovery mechanism for
schemas has already been batted around this list (and I believe I heard
something about some W3C activity starting in this area?). Getting all
the competing approaches behind a standard schema language is a major
prerequisite for this. It is hard to justify investing too much in
schema development and infrastructure if the final form and capabilities
of this schema language are still unclear. How and whether schemas will
then be made available is very much up in the air. The most promising
option I see is to create some kind of schema marketplace that will
enable people to get their schemas out there, with the metadata
necessary for others to find them, and let "free market" competition
decide which schemas will gain general acceptance. There are already
some efforts of this type, but they smack a little of marketing
manoeuvres controlled by a single company and not real attempts to
create an open marketplace.

Matthew

Jerome McDonough wrote:
> 
> For what it's worth (and my opinion and $2.50 will buy you a latte at
> Starbucks),
> I agree pretty much completely with your rant (except for the gratuitous dig
> at the HyTime guys, who History Will Prove Were On The Side of Right).
> XML doesn't address the problems of interoperability at the level you're
> talking
> about, and neither does RDF.  What you're talking about, unfortunately, is
> establishing standardized controlled vocabularies, and those are a ton of
> work.  They're hellish enough to develop in a relatively small, cohesive
> community
> like librarians.  There's no way in hell you're going to get competing
> companies
> to sit down at a table long enough to do this.
> 
> I suspect what this will probably mean is a variety of grass-roots efforts
> where people
> in particular communities who care enough will establish their own schemas
> with
> controlled vocabularies, and if they see enough use, software companies that
> deal with those communities will start altering their software to make use of
> that fact.  I see a possible danger here in that this might start reifying
> intellectual
> boundaries between communities and make it harder to search for information
> outside your common field of intellectual practice.  Schema repositories will
> help this problem somewhat by making schemas for intellectual domains you're
> not familiar with more generally available, but getting those up and running
> will
> also involve a lot of hard work.
> 
> TANSTAAFL still holds as a universal principle.  But for those who
> really care about trying to achieve interoperability and more open exchange
> of information, XML will still be used.

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



From anandram at wipsys.soft.net  Mon Nov  1 13:38:44 1999
From: anandram at wipsys.soft.net (Anand Raman)
Date: Mon Jun  7 17:16:24 2004
Subject: Query languages
Message-ID: <381D968E.D9D84D24@wipsys.soft.net>

Hi all
A few weeks ago (when i started to learn XML) i heard about a query
language called XQL .. Is it being supported by any main stream browser
or are there any other options for XQL
Thanx a lot
Anand Raman


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



From mrossi at crusher.jcals.csc.com  Mon Nov  1 16:21:02 1999
From: mrossi at crusher.jcals.csc.com (Michael Rossi)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
Message-ID: <472EF0A38796D21185810000F807DD1E5E4785@crusher.jcals.csc.com>

Matthew Gertner wrote:
> 
> I totally agree. The idea of some kind of discovery mechanism for
> schemas has already been batted around this list (and I believe I heard
> something about some W3C activity starting in this area?). Getting all
> the competing approaches behind a standard schema language is a major
> prerequisite for this. It is hard to justify investing too much in
> schema development and infrastructure if the final form and capabilities
> of this schema language are still unclear. How and whether schemas will
> then be made available is very much up in the air. The most promising
> option I see is to create some kind of schema marketplace that will
> enable people to get their schemas out there, with the metadata
> necessary for others to find them, and let "free market" competition
> decide which schemas will gain general acceptance. There are already
> some efforts of this type, but they smack a little of marketing
> manoeuvres controlled by a single company and not real attempts to
> create an open marketplace.

   What you're describing sounds an lot like the Registry and Repository
services that OASIS (http://www.oasis-open.org) claims to be setting up on
XML.org (http://www.xml.org). Biztalk (http://www.biztalk.org) seems to have
similar intentions, but I assume that's the 'single company marketing
manouver' to which you've referred.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 17:41:56 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:16:25 2004
Subject: Any DTD for DATE, URL, PRICE ??
Message-ID: <33D189919E89D311814C00805F1991F7F4A76D@RED-MSG-08>

Common notations such as DATE or URL are supported in the XML-DR schema
notation in the Microsoft  MSXML parser, and are also part of the schema
activity at the W3C.  See http://msdn.microsoft.com/xml/default.asp and
http://www.w3.org/XML/Activity.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 17:45:14 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:16:25 2004
Subject: Referencing multiple DTD in an XML document
Message-ID: <33D189919E89D311814C00805F1991F7F4A76E@RED-MSG-08>

A DOCTYPE cannot directly reference more than one DTD file.  To use several
such tags, you must either combine them in a single DTD, or use a schema
notation that supports such combination via namespaces, e.g. the XMLDR
schema notation currently in the Microsoft MSXML parser or the schema
notation under design at the W3C.  See
http://msdn.microsoft.com/xml/default.asp and
http://www.w3.org/XML/Activity.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 18:35:16 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:16:25 2004
Subject: Undeclared namespace
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E9025@sohos002.ied-support.net>

Thomas B. Passin wrote:
> Just to be complete even though you said you were joking, I 
> just rechecked
> using my copy of IE5.  The XML with DTD works even though there is no
> namespace attribute declared in the DTD.

Yes, but if you DO define the namespace attribute, it has to be #FIXED.
This seems to be generally accepted as incorrect. The XHTML DTDs include
the namespace attribute but it is not #FIXED, therefore totally valid
XHTML documents fail validation!

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 18:47:41 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:25 2004
Subject: XML for trade finance
In-Reply-To: <3280671C108AD311AA3600A0C9E11AF8033829@UKMAIL> (message from Jon
	Payne on Fri, 29 Oct 1999 04:46:36 -0700)
References: <3280671C108AD311AA3600A0C9E11AF8033829@UKMAIL>
Message-ID: <199910300419.XAA01141@bruno.techno.com>

> Does anyone know of any initiatives using XML in the field of trade finance?

I'm not sure that it's relevant, but you might check out
http://www.xmlmortgage.org

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 527 8553  <<-- new phone number, temporary
fax    +1 972 517 4571  <<-- new fax number, permanent
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 19:17:15 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:16:25 2004
Subject: Undeclared namespace
Message-ID: <33D189919E89D311814C00805F1991F7F4A77C@RED-MSG-08>

Mark Birbeck, regarding the Microsoft MSXML parser handling of xmlns
attributes in DTDs, wrote "This seems to be generally accepted as
incorrect."  

Scanning the archives will reveal that the interaction of namespaces and
DTDs is one in which every decision has drawbacks. Microsoft took the most
conservative position.  This may not have been the best course (though
debate here on XML-Dev and elsewhere does not seem to reach a settled
technical conclusion), but in any case, by virtue of being conservative, it
leaves open the possibility of loosening the handling in the future if the
least-problematic behavior becomes known, whereas the reverse would not have
been true.  

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 19:18:10 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
Message-ID: <001501bf24a1$21ad66d0$58f96d8c@NT.JELLIFFE.COM.AU>


From: Matthew Gertner <matthew@praxis.cz>

>I totally agree. The idea of some kind of discovery mechanism for
>schemas has already been batted around this list (and I believe I heard
>something about some W3C activity starting in this area?). Getting all
>the competing approaches behind a standard schema language is a major
>prerequisite for this

I certainly agree that a discovery mechanism for schemas is needed, but
I don't agree on the importance of having a single standard schema
language.

Every schema language is built on a zillion trade-offs. The best we can
hope for is that a schema language will be wonderful on some major
application domain and not entirely useless generally.  Would EXPRESS be
wonderful for describing TEI?  Would XML Schemas be wonderful for WAI
guidelines? Would Schematron be wonderful for VML?  Probably not.

We need the equivalent of the XML Stylesheet declaration (PI) so that
alternative schemas can be available  (perhaps with one being the
canonical schema) and so that use of a document is not dependent on
buying into a particular schema 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 19:24:02 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
In-Reply-To: <381D7A24.393CABBE@praxis.cz>
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de>
 <199910291614.MAA27642@westnet.com>
Message-ID: <199911011923.OAA21059@hesketh.net>

At 12:31 PM 11/1/99 +0100, Matthew Gertner wrote:
>I totally agree. The idea of some kind of discovery mechanism for
>schemas has already been batted around this list (and I believe I heard
>something about some W3C activity starting in this area?). 

The more I've worked with XML, the less convinced I've become that central
repositories for schemas hold a meaningful answer to information
processing.  While access to prior work is useful for reference, learning,
and some avoidance of reinventing the wheel, I don't think the dream of
schema repositories as standards bodies makes sense.  (I used to, really!)

>Getting all
>the competing approaches behind a standard schema language is a major
>prerequisite for this.  

I'm not convinced that this is actually critical.  You can start with DTDs
or XML-Data and move around as necessary - try out XML Authority
(www.extensibility.com) for one example of a tool that makes it very easy
to convert among different schema vocabularies.  Data type information can
be stored in DTDs quite easily, for instance, and put into a schema format
when appropriate.  This approach reduces the seemingly high cost of
switching infrastructures.

Rick Jelliffe's Schematron is another interesting option, providing
supplemental tests that aren't typically included in schemas.  Multiple
schema languages may in fact provide useful tools that a single vocabulary
and structure might not easily include.

>It is hard to justify investing too much in
>schema development and infrastructure if the final form and capabilities
>of this schema language are still unclear. How and whether schemas will
>then be made available is very much up in the air. The most promising
>option I see is to create some kind of schema marketplace that will
>enable people to get their schemas out there, with the metadata
>necessary for others to find them, and let "free market" competition
>decide which schemas will gain general acceptance. There are already
>some efforts of this type, but they smack a little of marketing
>manoeuvres controlled by a single company and not real attempts to
>create an open marketplace.

It's interesting, though, that the 'marketing manoeuvres' fosters this kind
of open competition, while the more neutral body has set up a formal
process for settling on schemas through closed committees.

I'm not sold on the need for single schemas for particular markets, nor do
I think a single repository is going to make that much difference (except
perhaps for PR).  

In some cases, companies will be able to agree on industry-wide standards,
but I don't think that approach is the only path forward.  XML's
transformability (courtesy of its structures plus XSL, Omnimark, MDSAX, and
other tools) opens the door to a Babel-like world in which we have a
significant - and adquate - chance of understanding each other without
having to proceed in lockstep.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From liamquin at interlog.com  Mon Nov  1 19:45:24 1999
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
In-Reply-To: <001501bf24a1$21ad66d0$58f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <Pine.BSI.3.96r.991101144558.14068D-100000@shell1.interlog.com>

On Tue, 2 Nov 1999, Rick Jelliffe wrote:
> We need the equivalent of the XML Stylesheet declaration (PI) so that
> alternative schemas can be available  (perhaps with one being the
> canonical schema) and so that use of a document is not dependent on
> buying into a particular schema language.

If you want every XML system to understand a schema, then you need
a different model.  You need a single VERY simple core schema language
that all XML 1.2 (say) validating processors are *required* to understand,
and make it extensible.

Otherwise one person will use SQL, another tcl, another LISP s-exprs,
another PROLOG Horn Clauses, and there will be no interoperability.

And XML is all about inteoperability.

The XML Stylesheet declaration, by the way, should have been done with
XLink.  The fact that an XML document does not use the XML linking
mechanism for links to its DTD and components indicates a problem.

In our case, the problem is that XLink wasnt invented, of course.

Lee

-- 
Liam Quin, Barefoot Computing, Toronto;  The barefoot agitator
l i a m q u i n     at    i n t e r l o g    dot   c o m
Ankh on irc.sorcery.net


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



From matthew at praxis.cz  Mon Nov  1 20:48:30 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
References: <001501bf24a1$21ad66d0$58f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <381DFC5A.4EBD28A0@praxis.cz>

Rick Jelliffe wrote:
> I certainly agree that a discovery mechanism for schemas is needed, but
> I don't agree on the importance of having a single standard schema
> language.
> 
> Every schema language is built on a zillion trade-offs. The best we can
> hope for is that a schema language will be wonderful on some major
> application domain and not entirely useless generally.  Would EXPRESS be
> wonderful for describing TEI?  Would XML Schemas be wonderful for WAI
> guidelines? Would Schematron be wonderful for VML?  Probably not.
> 
> We need the equivalent of the XML Stylesheet declaration (PI) so that
> alternative schemas can be available  (perhaps with one being the
> canonical schema) and so that use of a document is not dependent on
> buying into a particular schema language.

I buy somewhat that completely different metalanguages might be needed
for very different uses of XML. This could be plausibly said of XML used
for documents and XML used for data. However, this is a trend that
should certainly be avoided if at all possible. It is true that it is
quite easy to convert from one schema language to another, but this
doesn't exactly increase the convenience of using the stuff. Imagine you
have a graphical schema editor, an instance editor, a Java class library
and a browser and they all use different schema languages, for example.
Also, schema languages are not going to be entirely equivalent. The
specificities of a particular approach will be an important guide as to
how schemas should be designed and modularized, and these won't
necessarily map well from one variant to another.

An XML-syntax-based schema language based on element type descriptions
(rather than assertions or whaterver) that includes features for
combining and extending schemas is certainly not impossible to design
(there are a bunch of variants out there already), and this would be
perfectly fine for the examples you mention. Certainly specialized
languages may emerge, but when you consider how entrenched DTDs have
been, despite their significant weaknesses, it is plausible that the
current glut of approaches is more a response to a currently unfilled
market need than an indication that we really need a so many
alternatives.

Matthew


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



From matthew at praxis.cz  Mon Nov  1 20:48:33 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de>
	 <199910291614.MAA27642@westnet.com> <199911011923.OAA21059@hesketh.net>
Message-ID: <381DF82A.A7DEE224@praxis.cz>

Simon St. Laurent wrote:
> It's interesting, though, that the 'marketing manoeuvres' fosters this kind
> of open competition, while the more neutral body has set up a formal
> process for settling on schemas through closed committees.
> 
> I'm not sold on the need for single schemas for particular markets, nor do
> I think a single repository is going to make that much difference (except
> perhaps for PR).
> 
> In some cases, companies will be able to agree on industry-wide standards,
> but I don't think that approach is the only path forward.  XML's
> transformability (courtesy of its structures plus XSL, Omnimark, MDSAX, and
> other tools) opens the door to a Babel-like world in which we have a
> significant - and adquate - chance of understanding each other without
> having to proceed in lockstep.

Okay, let's put it this way: I can see your point that a central
repository has significant weaknesses. The idea of an automatic
discovery mechanism is much more promising. This is where you start to
run into questions of vision (i.e. I'm probably wrong), but think back
to how unimaginable the wealth of information available on the Web would
have been a few years back. (Actually what's really unimaginable to me
is how we got along without this.) It would have seemed outrageous only
10 years ago that it would soon be possible to find, say, the full text
of an ISO standard, Hamlet and the screenplay to Pulp Fiction in ten
minutes sitting at your computer, not to mention ordering a video, a
pizza and a car. Now transpose that to the software engineering field.
Is it really so crazy to suppose that programmers (and other creators of
metadata) might publish their information in a way that can be
discovered and reused by many others, both programmers and
non-programmers?

This idea has been derided by some because it smacks of AI technologies
that have been heavily hyped and then failed to materialize in the past.
But a simple full-text search could be very effective on this volume of
data. Advances in full-text technology that have been designed to deal
with the gigabytes of the Web could be heavily leveraged in this
scenario. Competition would also spout up among portals who would choose
and classify schemas. I find the idea of a Yahoo for schemas very
plausible; as with the real Yahoo, they would not actually author the
schemas themselves, but they would serve an important role in weeding
out the junk and sorting the rest.

Matthew



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 21:20:50 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:16:25 2004
Subject: Undeclared namespace
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E9027@sohos002.ied-support.net>

Andrew Layman wrote:
> Mark Birbeck, regarding the Microsoft MSXML parser handling of xmlns
> attributes in DTDs, wrote "This seems to be generally accepted as
> incorrect."  
> 
> Scanning the archives will reveal that the interaction of 
> namespaces and
> DTDs is one in which every decision has drawbacks. Microsoft 
> took the most
> conservative position.  This may not have been the best course (though
> debate here on XML-Dev and elsewhere does not seem to reach a settled
> technical conclusion), but in any case, by virtue of being 
> conservative, it
> leaves open the possibility of loosening the handling in the 
> future if the
> least-problematic behavior becomes known, whereas the reverse 
> would not have
> been true.  

I was trying to respond to the other messages without re-opening old
wounds Andrew, but since you have ...

I seem to remember the only person who hadn't reached a 'settled
technical conclusion' was you. From my recollection of the debate no-one
was saying how grateful they were that a namespace attribute declaration
had to be #FIXED. The reason for that is obvious; every single DTD that
specifically declares a namespace attribute but doesn't use #FIXED will
cause a validation error. Yet there is nothing in XML 1.0 or the
namespace rec that indicates this should be the case. As is often
pointed out on this list, DTDs know nothing of namespaces. As far as
DTDs are concerned it's just another attribute. If the DTD designer
wants that particular attribute to always have the same value then
that's up to them to declare it, but it shouldn't be built into the DOM!

This whole 'conservative' and 'future loosening' thing is just rubbish.
You make it sound like a minor problem which may or may not be fixed in
the future. But don't you see that the consequence of your developers'
preference has made DTDs over which one has no control completely
unusable? The most significant for me are the three for XHTML.

Mark Birbeck

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 21:24:03 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
In-Reply-To: <381DF82A.A7DEE224@praxis.cz>
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de>
 <199910291614.MAA27642@westnet.com>
 <199911011923.OAA21059@hesketh.net>
Message-ID: <199911012123.QAA28988@hesketh.net>

At 09:29 PM 11/1/99 +0100, Matthew Gertner wrote:
>Okay, let's put it this way: I can see your point that a central
>repository has significant weaknesses. The idea of an automatic
>discovery mechanism is much more promising. This is where you start to
>run into questions of vision (i.e. I'm probably wrong), but think back
>to how unimaginable the wealth of information available on the Web would
>have been a few years back. [...good stuff...]
>Now transpose that to the software engineering field.
>Is it really so crazy to suppose that programmers (and other creators of
>metadata) might publish their information in a way that can be
>discovered and reused by many others, both programmers and
>non-programmers?

I like where this is going - but it changes 'a plea for schemas' to 'a plea
for a discovery mechanism for information about XML documents'.  I think
you've got the right idea here, a way to keep the open approach of the
BizTalk schema repository without the baggage of the BizTalk framework and
its owners.  Instead of the centrally adjudicated process, we get an open
system for describing information that can be distributed rather than
centralized.

I'd like to think the W3C's new XML Packaging approach will provide some
tools for this, though it's too early to see where it's going.

>This idea has been derided by some because it smacks of AI technologies
>that have been heavily hyped and then failed to materialize in the past.
>But a simple full-text search could be very effective on this volume of
>data. Advances in full-text technology that have been designed to deal
>with the gigabytes of the Web could be heavily leveraged in this
>scenario. Competition would also spout up among portals who would choose
>and classify schemas. I find the idea of a Yahoo for schemas very
>plausible; as with the real Yahoo, they would not actually author the
>schemas themselves, but they would serve an important role in weeding
>out the junk and sorting the rest.

I'm not even concerned about 'weeding out the junk' - I'm more concerned
that everyone who writes a schema or even a textual description of a
document structure has a means to publish that information.  If aggregators
wants to provide rating services on top of that, but it's more important to
me that I be able to do things like:

<memo xmlns="mailto:simonstl@simonstl.com">
<to>You!</to>
<from>Me!</from>
<contents>Hi there!</contents>
</memo>

and have some way for recipients of this message to process/transform it
into their own preferred memo format without requiring them necessarily to
contact me about it.

The tools you're talking about seem to let us both get the work we need done.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 21:34:29 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:16:25 2004
Subject: Undeclared namespace
Message-ID: <33D189919E89D311814C00805F1991F7F4A784@RED-MSG-08>

Would you seriously like me to go on a campaign to change this?  I can.  But
before you say "yes," though, please make sure that you have a settled,
detailed technical proposal that you are all happy with, is tested, and that
is agreed on by the relevant W3C activities.  If you do that, I will be
happy to ask to have the behavior changed. 

-----Original Message-----
From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net]
Sent: Monday, November 01, 1999 1:19 PM
To: xml-dev@ic.ac.uk
Subject: RE: Undeclared namespace


Andrew Layman wrote:
> Mark Birbeck, regarding the Microsoft MSXML parser handling of xmlns
> attributes in DTDs, wrote "This seems to be generally accepted as
> incorrect."  
> 
> Scanning the archives will reveal that the interaction of 
> namespaces and
> DTDs is one in which every decision has drawbacks. Microsoft 
> took the most
> conservative position.  This may not have been the best course (though
> debate here on XML-Dev and elsewhere does not seem to reach a settled
> technical conclusion), but in any case, by virtue of being 
> conservative, it
> leaves open the possibility of loosening the handling in the 
> future if the
> least-problematic behavior becomes known, whereas the reverse 
> would not have
> been true.  

I was trying to respond to the other messages without re-opening old
wounds Andrew, but since you have ...

I seem to remember the only person who hadn't reached a 'settled
technical conclusion' was you. From my recollection of the debate no-one
was saying how grateful they were that a namespace attribute declaration
had to be #FIXED. The reason for that is obvious; every single DTD that
specifically declares a namespace attribute but doesn't use #FIXED will
cause a validation error. Yet there is nothing in XML 1.0 or the
namespace rec that indicates this should be the case. As is often
pointed out on this list, DTDs know nothing of namespaces. As far as
DTDs are concerned it's just another attribute. If the DTD designer
wants that particular attribute to always have the same value then
that's up to them to declare it, but it shouldn't be built into the DOM!

This whole 'conservative' and 'future loosening' thing is just rubbish.
You make it sound like a minor problem which may or may not be fixed in
the future. But don't you see that the consequence of your developers'
preference has made DTDs over which one has no control completely
unusable? The most significant for me are the three for XHTML.

Mark Birbeck

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



From jelks at jelks.nu  Mon Nov  1 21:42:16 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:25 2004
Subject: A Plea for Schemas
In-Reply-To: <001501bf24a1$21ad66d0$58f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <NBBBICMNIPCICMKJECCBOENKDAAA.jelks@jelks.nu>

Rick Jelliffe wrote:

> We need the equivalent of the XML Stylesheet declaration (PI) so that
> alternative schemas can be available  (perhaps with one being the
> canonical schema) and so that use of a document is not dependent on
> buying into a particular schema language.

or dependent on buying into namespaces ...

/Jelks


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



From rev-bob at gotc.com  Mon Nov  1 21:47:07 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:26 2004
Subject: XML Client detection
Message-ID: <199911011647346.SM00215@Unknown.>

Hi there.  I'm new to this list, so hopefully someone else has already tackled this problem 
and has an answer handy.  ;)

I am a content provider; I'm the webmaster for www.gotc.com.  I've already tricked out 
a way to generate my pages as both HTML (*.html) and XHTML (*.xml), and I have 
the architecture set up so that I can conceivably switch visitors to the appropriate pages 
automatically.  The idea is that when an XML-compliant browser visits the site, it will be 
directed to the XHTML pages, and the rest will be shunted over to the HTML pages.  
(iHTML is a godsend for such matters....)

Some of you have probably already seen the problem: I need a way to detect XML 
compliance from the server level, using only the data normally sent to the server by the 
UA.  My initial thought is to go by the user agent string in some fashion; if nothing else, I 
could keep a list of UA "signature" strings which are XML-compliant, test for them, and 
act accordingly...yet this seems to be rather the long way around.  Not for the first time, 
I find myself wishing that there was some sort of standard way for UAs to list their 
capabilities for the server - something perhaps as simple as a parenthetical string of the 
type (HTML4,XML1,CSS2).

Does anyone have either (a) a partial list of XML-compliant browser UA strings or (b) a 
suggestion for an alternate approach?



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 22:02:25 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun  7 17:16:26 2004
Subject: Undeclared namespace
In-Reply-To: <33D189919E89D311814C00805F1991F7F4A784@RED-MSG-08>
Message-ID: <4.2.1.10.19991101165655.00b8c740@pophost1.fore.com>

At 01:33 PM 11/01/99 -0800, Andrew Layman wrote:
>Would you seriously like me to go on a campaign to change this?  I 
>can.  But
>before you say "yes," though, please make sure that you have a settled,
>detailed technical proposal that you are all happy with, is tested, and 
>that
>is agreed on by the relevant W3C activities.  If you do that, I will be
>happy to ask to have the behavior changed.

Just curious:  Does this mean that the current behavior is the result of a 
detailed technical proposal that all XML developers are happy with, and 
that was tested, and that has been agreed to by the relevant W3C 
activities?

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

Mark Nutter, <mnutter@fore.com>
Internet Applications Developer
FORE Systems
"I'm not an actor, but I play one on TV..."


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



From tpassin at mitretek.org  Mon Nov  1 22:37:43 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
Message-ID: <003801bf24b9$9d999120$38a3f1ce@ls-.mitretek.org>

Everyone seems to have something really useful to say about schemas.  I'd like
to add a few thoughts, too.

First, one of the strengths of XML, as I see it, is that you don't NEED to have
a DTD - validation is optional.  This means you can still parse and use a
document if you can't get hold of its DTD (or, let us hope, its schema of
whatever variety).  Perhaps you would really like to have it when you create the
document, and the user-end processor could of course be designed to require the
DTD.  But at least you can design your system not to need it if you want.

This is useful because you can now work if the internet isn't available, or if
you didn't download the current version of the DTD, etc.  It also means there
are fewer internet connections, so it is faster.  When I tried out several SGML
browsers a few years ago, it seemed like I was always waiting for some for one
or another part of the system to lead - and sometimes some crucial part failed
to come in at all.  I ended up not very happy with the process.  I imagine
that's one reason that XML - which was developed to "put SGML on the Internet",
doesn't require the DTD.  So we should not require any other schema to be
present, either.

This suggests that if an XML document specifies a schema whose type is not known
to the XML processor, the processor should ignore it.  This is consistent with
current processors being allowed to ignore entities defined in external DTDs, if
the processor is not doing validation.  In turn, this reinforces the notion that
it is useful not to require the user end processor to do validation-type things.
And this in turn is very applicable to use over the internet - the less
complexity you require, the more likely that things will work.

Second, the suggestions for a general way to specify alternate schema styles
sound really interesting.  Possibly it could be done now through a Processing
Instruction without needing any syntax change to XML.  Or, as Microsoft is
trying out in IE5, through a specific namespace - but that would only work for
XML-syntax schemas, and therefore not for DTDs as we know them.  But I don't
think that a general purpose XML processor should be required to understand them
all or to convert between them.

Third, with regards to the discussions about a schema repository, what needs
should it serve? That is the salient question that should be worked out before
many of the other questions can be answered.  Since I think that the need for
on-line or user-end schemas should be minimized, I think a repository should not
be needed for on-line, day-in and day-out processing.  In this view, a schema
repository would be more of an archive, to be used for reference and to get
copies of schemas for use by developers and, perhaps, creators of content (human
or otherwise).

This is starting to seem pretty long-winded, so I'll stop here.

Tom Passin

From: Simon St.Laurent <simonstl@simonstl.com>


>At 12:31 PM 11/1/99 +0100, Matthew Gertner wrote:
>>I totally agree. The idea of some kind of discovery mechanism for
>>schemas has already been batted around this list (and I believe I heard
>>something about some W3C activity starting in this area?).
>
>The more I've worked with XML, the less convinced I've become that central
>repositories for schemas hold a meaningful answer to information
>processing.  While access to prior work is useful for reference, learning,
>and some avoidance of reinventing the wheel, I don't think the dream of
>schema repositories as standards bodies makes sense.  (I used to, really!)
>
>>Getting all
>>the competing approaches behind a standard schema language is a major
>>prerequisite for this.
>
>I'm not convinced that this is actually critical.  You can start with DTDs
>or XML-Data and move around as necessary - try out XML Authority
>(www.extensibility.com) for one example of a tool that makes it very easy
>to convert among different schema vocabularies.  Data type information can
>be stored in DTDs quite easily, for instance, and put into a schema format
>when appropriate.  This approach reduces the seemingly high cost of
>switching infrastructures.
>
>Rick Jelliffe's Schematron is another interesting option, providing
>supplemental tests that aren't typically included in schemas.  Multiple
>schema languages may in fact provide useful tools that a single vocabulary
>and structure might not easily include.
>
>>It is hard to justify investing too much in
>>schema development and infrastructure if the final form and capabilities
>>of this schema language are still unclear. How and whether schemas will
>>then be made available is very much up in the air. The most promising
>>option I see is to create some kind of schema marketplace that will
>>enable people to get their schemas out there, with the metadata
>>necessary for others to find them, and let "free market" competition
>>decide which schemas will gain general acceptance. There are already
>>some efforts of this type, but they smack a little of marketing
>>manoeuvres controlled by a single company and not real attempts to
>>create an open marketplace.
>
>It's interesting, though, that the 'marketing manoeuvres' fosters this kind
>of open competition, while the more neutral body has set up a formal
>process for settling on schemas through closed committees.
>
>I'm not sold on the need for single schemas for particular markets, nor do
>I think a single repository is going to make that much difference (except
>perhaps for PR).
>
>In some cases, companies will be able to agree on industry-wide standards,
>but I don't think that approach is the only path forward.  XML's
>transformability (courtesy of its structures plus XSL, Omnimark, MDSAX, and
>other tools) opens the door to a Babel-like world in which we have a
>significant - and adquate - chance of understanding each other without
>having to proceed in lockstep.
>



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 22:55:56 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
Message-ID: <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca>

Useful discussion, hope lots of people are reading it.  

"Let a hundred flowers bloom" OK, but let a bunch of different schema
*languages* co-exist?  Aargh, this sounds like it makes life more difficult
than need be.

I share the doubt that a grand unified schema repository will be tractable
to build & maintain.  I also am enthusiasm-challenged because in my (lengthy)
experience with XML and its ancestors, I have only ever seen machine-readable
schemas put to use in one application: namely the use of DTDs in 
hand-authoring XML documents.  Clearly the addition of datatypes and so on
should enable all sorts of other goodies but we are all placing bets on
an as-yet-unrealized future.  So some degree of skepticism is in order.

Note "machine-readable" in the sentence above.  At this point in history,
it's the human-readable part of schemas that seem to me to have the
biggest payoffs, because that's what the programmers read before they
write the code that actually does something useful. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  1 23:01:32 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de> <381987FB.8AC832B7@praxis.cz>
Message-ID: <381E1B7F.BF9EE596@prescod.net>

It seems to me that you describe the crux of the metadata problem: even
technical people cannot be bothered to supply metadata to their standard
business documents. I don't see how new or better schema languages or
schemas will improve this situation. RDF's complexity is a problem, but
not THE problem. THE problem is that even when the metadata "framework"
is as easy as:

<meta name="author" value="Paul Prescod">

people will probably not use it unless they are forced to.

I suspect that the way forward is through the implementation of document
management within organizations. Once a critical mass of internal data
is properly labelled, that data can be made available on the Web using
standardized metadata vocabularies. Corporations have levers for
encouraging conformance that standardizers do not.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  1 23:34:52 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de> <381987FB.8AC832B7@praxis.cz> <381E1B7F.BF9EE596@prescod.net>
Message-ID: <381E222F.A73@hiwaay.net>

Paul Prescod wrote:
> 
> people will probably not use it unless they are forced to.
> 
> I suspect that the way forward is through the implementation of document
> management within organizations. Once a critical mass of internal data
> is properly labelled, that data can be made available on the Web using
> standardized metadata vocabularies. Corporations have levers for
> encouraging conformance that standardizers do not.

Coming in late to this, but IMHO, and after watching four billion 
spent on CALS, they will use it when it is easier to use than 
the alternatives immediately available and when RFPs require it.

How many of you know how to start, work, and complete an 
enterprise engineering project?  What tools would you use?

It is up to us to make schemas useful.  XML Doesn't Care.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 00:03:13 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:26 2004
Subject: Undeclared namespace
References: <33D189919E89D311814C00805F1991F7F4A784@RED-MSG-08>
Message-ID: <381E2A23.12A24D7F@prescod.net>

Here is my proposal:

Internet Explorer should not report errors about the intersection of
DTDs and namespaces beyond those specified by XML 1.0 and the namespaces
specification.

Or to put it another way:

Internet Explorer should accept any document that conforms to the XML
1.0 and XML namespaces specification.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 00:05:16 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
References: <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca>
Message-ID: <381E2AAD.AA7019CB@prescod.net>

Tim Bray wrote:
> 
> Note "machine-readable" in the sentence above.  At this point in history,
> it's the human-readable part of schemas that seem to me to have the
> biggest payoffs, because that's what the programmers read before they
> write the code that actually does something useful. -Tim

Any programmer that reads the prose but doesn't read the schema is bound
to make many avoidable assumptions and mistakes.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 00:33:10 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
In-Reply-To: <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca>
Message-ID: <000001bf24c9$fdd22f60$099918d1@docuverse1>

My opinion on unified schema repository is that it won't happen while
everyone is interested in it because expectation leads to escalating hype
and politics.  We already have multiple schema repositories now and there
will be more of them coming in the near future.

I have more hope for unified schema bridge registry which provides schema
conversion service either in downloadable or remote form.  Your software can
use the service at runtime to convert one XML format to another without
regard to schemas differences.  Some bridges will be generated automatically
but I do not see hand-built bridges going away ever.

The Unified Schema Bridge Registry will flatten the playing field and let
the market pick the best schemas.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 00:37:15 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
In-Reply-To: Paul Prescod's message of "Mon, 01 Nov 1999 18:05:01 -0600"
References: <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca> <381E2AAD.AA7019CB@prescod.net>
Message-ID: <m3n1sxk9xj.fsf@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> Tim Bray wrote:
> > 
> > Note "machine-readable" in the sentence above.  At this point in history,
> > it's the human-readable part of schemas that seem to me to have the
> > biggest payoffs, because that's what the programmers read before they
> > write the code that actually does something useful. -Tim
> 
> Any programmer that reads the prose but doesn't read the schema is bound
> to make many avoidable assumptions and mistakes.

Et vice-versa.  The only reason that formal languages are less
ambiguous than natural ones is that they're not capable of saying much
in the first place.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 00:45:41 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
In-Reply-To: Len Bullard's message of "Mon, 01 Nov 1999 17:28:47 -0600"
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de> <381987FB.8AC832B7@praxis.cz> <381E1B7F.BF9EE596@prescod.net> <381E222F.A73@hiwaay.net>
Message-ID: <m3k8o1k9k1.fsf@localhost.localdomain>

Len Bullard <cbullard@hiwaay.net> writes:

> How many of you know how to start, 

Easy-ish.

> work, 

Hard.

> and complete an enterprise engineering project?

Rarely seen.

> What tools would you use?

The delete key.  

The only way most projects actually get finished is when management is
forced to retract most of its requirements and decide which ones are
actually worth spending (limited) time and money on.  No advance
planning process seems capable of avoiding this problem.

> It is up to us to make schemas useful.  XML Doesn't Care.

Right, and it's far too early for us really to know what we need (as
Tim pointed out in a slightly different context).  

We're just *starting* to figure out what XML itself is useful for: a
single formal schema standard could certainly be convenient (to save a
bit of the work of writing validation software), but it's just another
accessory, like a stylesheet or API standard.

My customers rarely ask about schemas -- they're a lot more worried
about transfer protocols and digital signatures.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 00:55:45 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
Message-ID: <3.0.32.19991101165503.00c8e950@pop.intergate.bc.ca>

At 07:43 PM 11/1/99 -0500, David Megginson wrote:
>My customers rarely ask about schemas -- they're a lot more worried
>about transfer protocols and digital signatures.

And when my customers *do* ask about schemas I start to get nervous,
as it is often a symptom of starry-eyed hope that when they write the
schema they've cracked the nut, and somehow "XML will do the rest." 
 -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 01:00:27 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
In-Reply-To: <m3n1sxk9xj.fsf@localhost.localdomain>
References: <Paul Prescod's message of "Mon, 01 Nov 1999 18:05:01 -0600">
 <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca>
 <381E2AAD.AA7019CB@prescod.net>
Message-ID: <199911020059.TAA15608@hesketh.net>

At 07:35 PM 11/1/99 -0500, David Megginson wrote:
>Paul Prescod <paul@prescod.net> writes:
>
>> Tim Bray wrote:
>> > 
>> > Note "machine-readable" in the sentence above.  At this point in history,
>> > it's the human-readable part of schemas that seem to me to have the
>> > biggest payoffs, because that's what the programmers read before they
>> > write the code that actually does something useful. -Tim
>> 
>> Any programmer that reads the prose but doesn't read the schema is bound
>> to make many avoidable assumptions and mistakes.
>
>Et vice-versa.  The only reason that formal languages are less
>ambiguous than natural ones is that they're not capable of saying much
>in the first place.

That last bit is a beautiful statement that sums it all up, though the
pieces above it both have merit.  

We need a standard way to get to all of that information, both machine- and
human- readable. Right now, all we have is a way to get a formal
description and a bunch of comments, if we're very lucky.

I'm strongly hoping that both the XML Schemas and XML Packaging efforts
give very high priority to human-readable documentation.  I just finished
(yet another) XML book in which I felt every other sentence was "make sure
you document it for _people_, because if you don't, it's just more crap".

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov  2 02:27:20 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:26 2004
Subject: Undeclared namespace
Message-ID: <19991101212680.SM00154@Unknown.>

> Here is my proposal:
> 
> Internet Explorer should not report errors about the intersection of
> DTDs and namespaces beyond those specified by XML 1.0 and the namespaces
> specification.
> 
> Or to put it another way:
> 
> Internet Explorer should accept any document that conforms to the XML
> 1.0 and XML namespaces specification.

I could certainly get behind that implementation.  We've had enough fragmentation 
where HTML was concerned; XML offers an excellent chance to avoid that, but for this 
to be possible, the UAs *must* conform to the specs.  It's just that simple.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 02:30:25 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
References: <38196183.8B669A0A@praxis.cz>
Message-ID: <381E4BC7.72FE@hiwaay.net>

Matthew Gertner wrote:
> 
> I have written a short "XML Rant" 

Enjoyable.  It is good to see some reasonable passion from a 
reasonable mind.  Here is some rant for the rant.

o  "the 1980s, Charles Goldfarb invented SGML".  Ok for a 
rant, but ISO created SGML. If any man can be said to 
have lead that work, it is Dr. Charles Goldfarb at IBM Almaden.
He was a member of the IBM team (Goldfarb, Mosher, Lorie) that designed,
GML.  
To the idea of GenCodes, GML added among other things, 
type-defined namespaces for markup. GML and research were combined to 
propose and ratify ISO 8879.  Invention like that is a community 
process.  Dr. Goldfarb leads that community.

In the late 1960s, publishers needed a means to 
exchange working files.  A solution proposed at that time, 
GenCodes, was supported.  The limited power of sharing 
the same single namespace (the Gencodes) did not evolve.  
The reasons are not complex and are the same as HTML: 
the namespace represents a local application context.  
When shared for all types, it limits the expressiveness 
needed to document multi-context real time events.

o  "..thousands loved it."  Conceded.  SGML was an expensive 
system deployed on then mostly mainframe and mini environments. 
Who had it?  Aerospace tech writers, some artists, and lawyers.
Why?  They had a use for it and the costs were justified 
relative to the cost of the lifecycle of the information 
in its topical context.  Manuals.  Expensive ones.
 
SGML lends itself to interpreted means and interpreted 
means are inefficient.  That is relative to resources.  
As soon as SGML was moved to PC-based systems, 
it became cost-effective.  There are and were examples of 
SGML-based systems working well for hypertext client 
applications in those environments.  Except for 
lowlyIADS, mostly expensive ones.  Systems like 
IADS proved SGML, if deFanged a bit, could be 
deployed cheaply.  Free even. 

IADS did not use a DTD.  It used a stylesheet (circa 1990).
It had a DTD, and the tags within it were modifiable and 
extensible via the stylesheet processor.  Its tags (file, frame,
hyperlink) 
were the equivalent of the ThenMalignedAndDespised PROCESSING
INSTRUCTIONS 
but they looked like tags, so DTDs written for the system 
incorporated them and went on about their business.  Framing worked.

In 1989:

1. Software was expensive
2. Hardware was expensive
3. The dominant application of SGML (1000dpi print) was hard.

SGML emerged into more general use when more power 
was on more desks.  Complexity coupled to complexity 
produces emergence.  TCO.  The critical innovation 
to enable the emergence of SGML came from Intel, et al.  
The unification of a significantly sized software base by a dominant 
operating system company did the rest.  Kick MS as much 
as people want to, without them, the Web today would 
still be something university students surfed and 
researchers occasionally mastered, IMNSHO. 

HTML emerged when:

o  The Internet was opened to commercial use
o  The power of the processor could support the 
   lowest-common denominator application of SGML
o  Governments paid to implement and give away 
   a means and process to share the namespace in that 
   application
o  A person to lead the effort emerged with a plan 
   that would work:  Tim Berners-Lee, HTTP and HTML.

These convergent events, all in the same five years, gave you the 
WorldWideWeb.

o  HTML is a subset of SGML:  NYET.  Get out the ruler 
and rap the knuckles.   XML is a subset of SGML.  HTML 
is an *application* of SGML.  It is obnoxious, and I 
apologize in advance, but getting others to understand 
**that** critical difference in thinking about markup is 
very hard sometimes.  Where I put "application", some 
say, "vocabulary".  Que bueno, but as Charles said, 
"conserve names" and that is all.  

Systems are invented or specified.  Vocabularies are spoken.

HTML was not hobbled.  It was distilled like other vocabularies 
from agreements made among organizations to share information. 
CERN, Univ of Ill, DARPA agree to make such agreements and 
vocabularies are the result of that agreement.  What the organizations 
share are namespaces and the implementations of processors for 
creating, adding, deleting, or modifying statements in those 
namespaces.  HTML was GenCode: partDeux.   TimBL gets the credit, 
but there were those who helped him and if you ask, I'm sure he 
will tell you names.  Names are what is shared.  

It's all about names.  Read the XML 1.0 and, IMHO, that 
is the conceptual breakthrough to understand markup.  In essence, 
SGML has always been principally a lexical standard.  That 
structural integrity is important, and specifying that 
provides the necessary freedom from implementation 
to enable an inexhaustible range of expression.  

It makes the agreement needed to implement a 
system to use it very expensive.  XML locks 
down the SGML Declaration.  Most of the biggest 
changes from SGML start there.  To keep the original 
expressive power, the means for making beyondLex agreements 
are still needed.

A DTD is not about lexical validation only.  It 
is about validating a hierarchical namespace to 
determine conformance.  Whether you use DTDs, 
MS Schemas, XML Schemas(someday), or just use 
the table design window for Access or Oracle, 
validating a vocabulary requires you to declare 
one or derive it.  IMHO, of the two means, declaration 
is usually cheaper, but it is always political. 
  
Politics are human means to declare namespaces. 
BizTalk and OASIS both exist because of the names 
and interest of those named in the shared politics 
of creating their shared namespaces.  That is all.

XML does not care.

Syntax unification is not enough.  Using markup systems 
requires you to accept the idea that the namespace is 
primary.  What does that mean?  Just as sql systems 
must disambiguate aggregate naming, so must markup systems. 
A name means what you need it to.  It must be unique and persistent 
to be a name and you require a means to discover if it is 
meeting that need.  Trust but verify.

Schemas are just one of the tools for discovering if 
that is the case.  You can do more with schema information 
in the same way the relational system does it.  Names 
are associated to create processable unique names.  

You can do a lot with the DTDs and schemas, really.  
They are just metainformation by which 
you agree to organize the screen and the objects on it, 
or the messages among objects, or whatever you want 
to talk about.  The reason to use them 
is to validate or as a source for initialization.  In 
effect, they really are, just another database of 
names and values.  That is what makes using XML 
Schemas (in deference to DTDs), attractive.  Application 
outside very specialize ISO 8879-conforming processors 
for DTDs are also useful for managing the namespace 
of that metainformation.

DTDs do not aggregate; so, if instances do, they 
are not validatible.  That does not keep them from 
being useful.  The names in the space are unique. 
Their persistence is questionable, yet if you treat 
them as a relational designer treats a view, they 
are very useful.  Well-formed is what you need for 
any lifecycle of the information.  Valid is what 
you need to ensure correct processes among systems 
that use the information at particular times.  When 
a formal means to persist these better is provided, 
then we have a very good system for maintaining 
namespace communities.

Schemas organize a namespace; not doing that is 
relaxing a design constraint on the namespace.  Relaxing 
that constraint is efficient particularly at this 
time when database systems are so cheap and ubiquitous, 
using them for serving strings is optimal.  Correct-
by-construction from a trusted source is faster, 
more compact, and less-restricting on system evolution.

Badly-formed HTML?  It was a trade-off.  It cleans 
up over time.  Better tools, better hunts, better times.

All XML says is, you don't have to use the DTD.  
It doesn't say it isn't useful. Enlightened XMLers 
write them and use them and even throw them away.  
A DTD is snapshot of the organization of a namespace 
in time.  Time moves on.  Information does too.  
The DTD might not.  Some part of it probably 
will and will influence the next version. The 
reason to use or not use a DTD or any other 
schema is determined by the namespace evolution: 
and evolution of agreements, so cooperation.

Cooperation among large human communities is 
always furthered when agreements about what 
to name the names are simple and easy to verify. 
When the means to communicate among companies 
became the Web, the need to verify these agreements 
by simple means became an ecological imperative. 
So, patience.  But don't quit pleading.  Namespaces 
are gardens.  To grow usefully, they have to be tended. 
It takes tools, lots of them, for particular 
purposes, to do that. Most of us have sheds full of 
tools we only use occasionally next to ones we use 
every day.

That golden 10% of XML is the distilled essence of 
SGML and the years of practice and competing, sometimes 
awkward specifications and standards written there 
by all of the people I met in those years.  Even 
those HyTime guys worked on creating XML.  HyTime, 
DSSSL, TEI, but before them, Dexter, FRESS, Englebart, 
all feed the single stream that is now XML and as 
with SGML, all the competing, sometimes awkward 
specifications being written by many of the same people.

If you want to plead for schemas, I plead with you.  Schemas are a 
tool for validating agreements among overlapping namespace 
communities.  Ecom-ecologies (keiretsu) emerge because 
the tools they use to make agreements, their namespaces, 
become efficient.  S=KlogW - Boltzman.  To control 
the temperature, control the value of W.  DTDs help 
you control the rate at which entropy consumes referents.

The trick to fix the web is to fix the web's indexes. 
To do that, ensure the agreements by which the indexes 
are made enable validation of the namespaces indexed.
Well-formed, and valid by agreement are the keys to creating 
semantic space, overlapping vocabularies, if that is what 
you want.  

DTDs are a tool to make agreements.  Beyond the agreement are the 
names that agree.  XML Doesn't Care.  You do.  You write:

     Dilution of the basic principles of generic markup, and
     misunderstanding of their purpose, will then give rise to
inevitable
     disappointment, and hence rejection: "We switched our whole
     company over to XML and we still can't interchange data
effortlessly.
     So this means that XML doesn't work, right?" 

How many 'MLers here want a dollar for every time you've heard that?

Tell 'em, "ahh, XML Works.  We just don't agree on how."

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 02:37:46 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:26 2004
Subject: A Plea for Schemas
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de> <381987FB.8AC832B7@praxis.cz> <381E1B7F.BF9EE596@prescod.net> <381E222F.A73@hiwaay.net> <m3k8o1k9k1.fsf@localhost.localdomain>
Message-ID: <381E4DAB.5718@hiwaay.net>

David Megginson wrote:

Complete agreement with snipped sections.
 
> My customers rarely ask about schemas -- they're a lot more worried
> about transfer protocols and digital signatures.

Mine always do.  They want to convert the data they have into 
our relational system and want to estimate the cost ahead of time. 
They don't ask for DTDs.  We don't make any, but 
databases are databases.  Migration is seasonal.

The agreements about transfer protocols and digital authentication 
are in another part of the RFP. 

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 02:40:36 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
References: <3.0.32.19991101165503.00c8e950@pop.intergate.bc.ca>
Message-ID: <381E4E4A.5B8B@hiwaay.net>

Tim Bray wrote:
> 
> At 07:43 PM 11/1/99 -0500, David Megginson wrote:
> >My customers rarely ask about schemas -- they're a lot more worried
> >about transfer protocols and digital signatures.
> 
> And when my customers *do* ask about schemas I start to get nervous,
> as it is often a symptom of starry-eyed hope that when they write the
> schema they've cracked the nut, and somehow "XML will do the rest."
>  -Tim

When we get finished looking at their data and our schema and 
factoring the time to do the conversion, we let them decide 
who will pay to do the rest.  If they need XML for that, we'll 
give them XML... according to our schema. :-)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dwshin at nlm.nih.gov  Tue Nov  2 05:07:30 1999
From: dwshin at nlm.nih.gov (dwshin)
Date: Mon Jun  7 17:16:27 2004
Subject: XRS: XML retrieval engine is downloadable
Message-ID: <381E6F57.E66ABD6B@nlm.nih.gov>

Hello, folks:

XRS (XML Retrieval System) is an XML indexing and retrirval engine
that allows a variety of structural searching functions with less
indexing
overhead.

It is now downloadable at the site:
http://dlb2.nlm.nih.gov/~dwshin/xrs.html

At this time, only Solaris version is available, but Windows version
will also follow soon. You need to install servlet engine prior to
installing XRS.

Any comment and inquiry about XRS is welcome to
dwshin@nlm.nih.gov

Dongwook

------------------------------
Dongwook Shin
Visiting scholar
Lister hill Center in National Library of Medicine
http://dlb2.nlm.nih.gov/~dwshin
mail: dwshin@nlm.nih.gov


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 05:25:46 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:27 2004
Subject: Undeclared namespace
Message-ID: <004f01bf24f6$1d9238a0$46f96d8c@NT.JELLIFFE.COM.AU>

 From: Andrew Layman <andrewl@microsoft.com>

>Would you seriously like me to go on a campaign to change this?  I can.
But
>before you say "yes," though, please make sure that you have a settled,
>detailed technical proposal that you are all happy with, is tested, and
that
>is agreed on by the relevant W3C activities.  If you do that, I will be
>happy to ask to have the behavior changed.

There was a related problem in certain XML systems: if you used
"xml:lang" in a document they required a DTD; if you gave them a DTD
they gave an error claiming that there is an attempt to use the reserved
"xml:" prefix.

With QAML I just gave up using namespaces or requiring DTDs because I
couldn't find a combination that worked reliably on each system.  (This
was using an early IE5 and a very early LotusXSL.)

I hope that things have changed, but I don't know where people get the
idea that people will not use both namespaces and DTDs. Not the least
because DTDs can have infoset contributions that (perhaps) schemas do
not.

I think if Microsoft thinks that namespace attributes in DTDs should be
#FIXED, the correct place to get this happening is in the Namespace
Specification, not in some product.  I would welcome any attempt by
Andrew to get IE changed to something more useable.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 06:13:56 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
References: <3.0.32.19991101165503.00c8e950@pop.intergate.bc.ca>
Message-ID: <381E7FAD.73CA883D@prescod.net>

Tim Bray wrote:
> 
> At 07:43 PM 11/1/99 -0500, David Megginson wrote:
> >My customers rarely ask about schemas -- they're a lot more worried
> >about transfer protocols and digital signatures.

My customers and students are old-fashioned in comparison.

> And when my customers *do* ask about schemas I start to get nervous,
> as it is often a symptom of starry-eyed hope that when they write the
> schema they've cracked the nut, and somehow "XML will do the rest."

"To me programming is more than an important practical art. It is 
 also a gigantic undertaking in the foundations of knowledge."
         - Grace Hopper

By the time you have a schema for your domain you have mapped out your
communal understanding of that domain. In many areas that *is* cracking
the nut. As a practical example, consider word processing. By now there
are dozens of word processors and desktop publishers. It would be a
massive effort to come to understand their commonalities and define the
"universal DTP language."

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 06:31:45 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
Message-ID: <3.0.32.19991101223119.00c87b50@pop.intergate.bc.ca>

At 12:07 AM 11/2/99 -0600, Paul Prescod wrote:
>By the time you have a schema for your domain you have mapped out your
>communal understanding of that domain. 

This is a surprising and counter-intuitive assertion that needs some
supporting evidence.  I disagree.  I think large parts of the the 
"communal understanding" live in wetware between human ears and in messy
procedural code.

>In many areas that *is* cracking
>the nut.

Where I work, people aren't satisfied until there's running code that
does useful stuff, and the schema-ware is an essential but fairly small
component of getting there.

> As a practical example, consider word processing. By now there
>are dozens of word processors and desktop publishers. It would be a
>massive effort to come to understand their commonalities and define the
>"universal DTP language."

Huh?  Weren't we talking about schemas? -T.

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



From antons at epos.co.za  Tue Nov  2 06:49:05 1999
From: antons at epos.co.za (Anton Schoultz - ePOS)
Date: Mon Jun  7 17:16:27 2004
Subject: Parameter entities for DTD modularity (was: Re: Multiple docs in 'wrapper')
Message-ID: <NBBBLIPEHIMMNAPFNOLCCEJJEBAA.antons@epos.co.za>

Hi All,

Thanks for the input on the two questions I posed a few days back.

Re:Q1 - short answer NO
I will stick to single document type per exchange (i.e. only invoice(s) /
only payment(s) etc).

Re:Q2
For those fragments (such as address, email, date etc etc ) that are common
across my document types I'll probably define the fragment in it's own DTD
file, and then go with the ENTITY definition as outlined by Liam Quin [Sun
1999/10/31 09:30] to 'include' them in the required documents

Thanks again
Anton


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



From tania at bic.nus.edu.sg  Tue Nov  2 06:52:16 1999
From: tania at bic.nus.edu.sg (TaNiA)
Date: Mon Jun  7 17:16:27 2004
Subject: a newbie question
Message-ID: <007c01bf24fe$dd96bd80$52138489@bic.nus.edu.sg>

Hi all,

I'm totally new to XML and XSL.

I've found sites which explain about what XML and what XSL is, but no where
have I found a site which shows how to link XSL with XML.

Is there a good site for a comprehensive tutorial for XML that anyone can
recommend?

thanks in advance,
tania



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



From varun at chennai.tcs.co.in  Tue Nov  2 07:25:59 1999
From: varun at chennai.tcs.co.in (V Arun Kumar)
Date: Mon Jun  7 17:16:27 2004
Subject: a newbie question
Message-ID: <6525681D.0028B3B6.00@MAILSERVER2.chennai.tcs.co.in>



u could refer 14th chapter of this site "metalab.unc.edu/xml/books/bible" .this
material was of much use 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dag at orion.no  Tue Nov  2 07:52:35 1999
From: dag at orion.no (Dag Sunde)
Date: Mon Jun  7 17:16:27 2004
Subject: a newbie question
References: <007c01bf24fe$dd96bd80$52138489@bic.nus.edu.sg>
Message-ID: <02f001bf2506$d37895f0$43145c3e@orion.no>

Lifted from MS XML-site:
http://msdn.microsoft.com/xml/xslguide/xsl-template.asp

This is the file "Portfolio.xml":
( PS! take a close look at the second line; "href=..."

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="portfolio.xsl"?>
<portfolio xmlns:dt="urn:schemas-microsoft-com:datatypes"
xml:space="preserve">
  <stock exchange="nyse">
    <name>zacx corp</name>
    <symbol>ZCXM</symbol>
    <price dt:dt="number">28.875</price>
  </stock>
  <stock exchange="nasdaq">
    <name>zaffymat inc</name>
    <symbol>ZFFX</symbol>
    <price dt:dt="number">92.250</price>
  </stock>
  <stock exchange="nasdaq">
    <name>zysmergy inc</name>
    <symbol>ZYSZ</symbol>
    <price dt:dt="number">20.313</price>
  </stock>
</portfolio>


...and here comes "portfolio.xsl":

<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
  <xsl:template match="/">
    <HTML>
      <BODY>
        <TABLE BORDER="2">
          <TR>
            <TD>Symbol</TD>
            <TD>Name</TD>
            <TD>Price</TD>
          </TR>
          <xsl:for-each select="portfolio/stock">
            <TR>
              <TD><xsl:value-of select="symbol"/></TD>
              <TD><xsl:value-of select="name"/></TD>
              <TD><xsl:value-of select="price"/></TD>
            </TR>
          </xsl:for-each>
        </TABLE>
      </BODY>
    </HTML>
  </xsl:template>
</xsl:stylesheet>


Got it?

Dag Sunde.

----- Original Message -----
From: TaNiA <tania@bic.nus.edu.sg>
To: <xml-dev@ic.ac.uk>
Sent: Tuesday, November 02, 1999 7:52 AM
Subject: a newbie question


> Hi all,
>
> I'm totally new to XML and XSL.
>
> I've found sites which explain about what XML and what XSL is, but no
where
> have I found a site which shows how to link XSL with XML.
>
> Is there a good site for a comprehensive tutorial for XML that anyone can
> recommend?
>
> thanks in advance,
> tania
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From crism at exemplary.net  Tue Nov  2 08:47:43 1999
From: crism at exemplary.net (Christopher R. Maden)
Date: Mon Jun  7 17:16:27 2004
Subject: XML Client detection
Message-ID: <v01530500b4444cbf1d59@[209.157.134.40]>

[Rev. Robert L. Hood]
>Some of you have probably already seen the problem: I need a way to detect XML
>compliance from the server level, using only the data normally sent to the
>server by the
>UA.

Have you tried looking at the Accept: header?  It's a list of media types
accepted by the user agent; if it includes 'text/xml' or 'application/xml',
you should be able to send XML.

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111



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



From pvd_2000 at yahoo.fr  Tue Nov  2 09:10:08 1999
From: pvd_2000 at yahoo.fr (=?iso-8859-1?q?Vincent=20PHAM?=)
Date: Mon Jun  7 17:16:27 2004
Subject: XML for trade finance
Message-ID: <19991102091003.27290.rocketmail@web701.mail.yahoo.com>

  Which differences between IFX (Interactive Financial Exchange) and OFX (Open
Financial Exchange) ?

  Vincent PHAM
  IT Consultant, Altran, France.


=====

___________________________________________________________
Do You Yahoo!?
Votre e-mail @yahoo.fr gratuit sur http://courrier.yahoo.fr


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



From rgl at decisionsoft.com  Tue Nov  2 09:56:36 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
In-Reply-To: <3.0.32.19991101223119.00c87b50@pop.intergate.bc.ca>
Message-ID: <Pine.LNX.4.10.9911020944310.2146-100000@localhost.localdomain>

On Mon, 1 Nov 1999, Tim Bray wrote:
> At 12:07 AM 11/2/99 -0600, Paul Prescod wrote:

> >By the time you have a schema for your domain you have mapped out your
> >communal understanding of that domain. 

> This is a surprising and counter-intuitive assertion that needs some
> supporting evidence.  I disagree.  I think large parts of the the 
> "communal understanding" live in wetware between human ears and in messy
> procedural code.

Which is why, parenthetically, it's often quite awkward to process XML
using a declarative, rather than procedural, language.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


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



From matthew at praxis.cz  Tue Nov  2 09:54:22 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
References: <199910291034.MAA02484@mail.informatik.hu-berlin.de>
	 <199910291614.MAA27642@westnet.com>
	 <199911011923.OAA21059@hesketh.net> <199911012123.QAA28988@hesketh.net>
Message-ID: <381EB4C1.EBF7A163@praxis.cz>

"Simon St.Laurent" wrote:
> I like where this is going - but it changes 'a plea for schemas' to 'a plea
> for a discovery mechanism for information about XML documents'.  I think
> you've got the right idea here, a way to keep the open approach of the
> BizTalk schema repository without the baggage of the BizTalk framework and
> its owners.  Instead of the centrally adjudicated process, we get an open
> system for describing information that can be distributed rather than
> centralized.

How about a plea for both schemas and an associated discovery mechanism?
The former is clearly a prerequisite for the latter.

Matthew

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



From matthew at praxis.cz  Tue Nov  2 10:14:02 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
References: <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca>
Message-ID: <381EB94E.76946432@praxis.cz>

Tim Bray wrote:
> I share the doubt that a grand unified schema repository will be tractable
> to build & maintain.  I also am enthusiasm-challenged because in my (lengthy)
> experience with XML and its ancestors, I have only ever seen machine-readable
> schemas put to use in one application: namely the use of DTDs in
> hand-authoring XML documents.  Clearly the addition of datatypes and so on
> should enable all sorts of other goodies but we are all placing bets on
> an as-yet-unrealized future.  So some degree of skepticism is in order.

This is an easy issue to be sceptical about. It is worth keeping in
mind, however, that these historical arguments ("never needed it so I
probably never will") neglect the fact that many of the pieces of the
puzzle have been in place only recently (or are still being worked on):

* The right mindset: until very recently generic markup has been seen as
primarily useful for documents, where the utility of schemas is
admittedly limited for anything but authoring applications. The idea of
using XML as a software engineering tool to model data structures has
now become very prevalent.

* Critical mass: I'll put more effort into something if I can leverage
it across a wide user base. It's worth the effort to craft XML Schemas
and distribute them  because the community is so much bigger than it was
in the good old SGML days.

* Communications infrastructure: Something like an automatic discovery
mechanism for schemas would not be possible without widespread access to
a common network infrastructure.

* The schema language itself: IMHO DTDs are the weakest part of the
current XML standard. Hats off to the SGML inventors (I already got told
off for giving Dr. Goldfarb all the credit): most of what they started
doing in the 60s works very well in the late 90s. DTDs don't, as the
many "how do I combine these DTDs in a single instance" messages to this
list attest. A metalanguage that makes it easier to work with, combine
and extend schemas might plausibly increase willingness to use schemas.

So yes, some degree of skepticism is certainly in order, but this could
end up making the difference of an order of magnitude in the influence
that XML ends up having on information technology. We'll see.

Matthew

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



From matthew at praxis.cz  Tue Nov  2 10:28:38 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:27 2004
Subject: A Plea for Schemas
References: <38196183.8B669A0A@praxis.cz> <381E4BC7.72FE@hiwaay.net>
Message-ID: <381EBCD2.4155A283@praxis.cz>

Len Bullard wrote:
> Enjoyable.  It is good to see some reasonable passion from a
> reasonable mind.  Here is some rant for the rant.

Thanks, I hardly ever get called reasonable. :-)

> o  "the 1980s, Charles Goldfarb invented SGML".  Ok for a
> rant, but ISO created SGML. If any man can be said to
<snip many interesting details about the genesis of SGML>

> o  "..thousands loved it."  Conceded.  SGML was an expensive
<snip many interseting details about the rate of adoption of SGML and
the subsequent rise of HTML>

Really interesting stuff. When I first sat down and wrote the
introduction it was about 10 times longer and contained some of this
information, but it didn't seem especially relevant in the context of
pleaing for schemas, so I pared it down to the point where it is mostly
just a bunch of plausible-sounding lies. You know much more than me
about this anyway, so the decision was probably wise.

> o  HTML is a subset of SGML:  NYET.  Get out the ruler
> and rap the knuckles.   XML is a subset of SGML.  HTML
<snip clarification of the relationship between SGML and HTML>

Ouch. Whatever happened to poetic license? I thought "a hobbled subset
of SGML" sounded snappier than "an SGML application specifying a
vocabulary for the transfer and display of hypertext documents". The
latter would also have detracted from the humorous value of the
paragraph, of which there is hopefully at least some.

<more snipping>

> Tell 'em, "ahh, XML Works.  We just don't agree on how."

Seems like a healthy state of affairs. If we keep churning the idea
bucket the One True Way will eventually become obvious.

Matthew

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



From rev-bob at gotc.com  Tue Nov  2 10:42:29 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:27 2004
Subject: XML Client detection
Message-ID: <199911020542258.SM00154@Unknown.>

> [Rev. Robert L. Hood]

Please - Rev. Bob or even Bob is fine.  ;)

> >Some of you have probably already seen the problem: I need a way to detect XML
> >compliance from the server level, using only the data normally sent to the
> >server by the UA.
> 
> Have you tried looking at the Accept: header?  It's a list of media types
> accepted by the user agent; if it includes 'text/xml' or 'application/xml',
> you should be able to send XML.

Actually, no - I *hadn't* looked at that yet.  From what you say, provided I can access 
it, that should be exactly what I'm looking for in most cases, and may help with some 
other tailoring projects as well.

I just did a little looking around, though, and all is not exactly peachy.  For instance, one 
page I checked showed my HTTP_ACCEPT value as the following (using IE5):

   image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel,
   application/msword, application/vnd.ms-powerpoint, application/x-comet, */*

This seems to be all the *non-text* stuff IE5 can handle (including that little Comet 
Cursor control I installed a few days ago), but this still doesn't help much.  According to 
this, I can't even reliably test for being able to read HTML.  NN2.02 and NN4.7 are 
much the same, minus the application/* stuff and (in the case of NN4.7) adding the 
image/png type.  The "*/*" type is singularly useless, in that it can't possibly be accurate 
- ten years from now, that would match "image/holographic", but we know that wouldn't 
work in anything existing now.

In short, although the theory behind this sounds really neat at first, it doesn't look all that 
promising In Real Life.  (I appreciate the lead, though - does anyone else have something 
that might take us even further?)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 14:35:16 1999
From: nicmila at vscht.cz (Miloslav Nic)
Date: Mon Jun  7 17:16:28 2004
Subject: New Schematron examples using a new Schematron feature
Message-ID: <381EF695.EA03E42F@vscht.cz>

New examples were added to Schematron tutorial:
http://zvon.vscht.cz/HTMLonly/SchematronTutorial/General/contents.html

Example 16
Examples of Patterns for ID/IDREF Checking by Rick Jelliffe
and 
Example 14
The element must be a child of selected elements.
Example 15
If an element contains an attribute , the attribute name must be id.

These examples are using a new feature of
Schematron(http://www.ascc.net/xml/resource/schematron/schematron.html),
element <name/> which enables fine tuning of error messages.
-- 
***************************************************************
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  
****************************************************************
Support free information exchange: http://zvon.vscht.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 15:34:38 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:28 2004
Subject: A Plea for Schemas
References: <3.0.32.19991101223119.00c87b50@pop.intergate.bc.ca>
Message-ID: <381F0009.455D7333@prescod.net>

Tim Bray wrote:
> 
> At 12:07 AM 11/2/99 -0600, Paul Prescod wrote:
> >By the time you have a schema for your domain you have mapped out your
> >communal understanding of that domain.
> 
> This is a surprising and counter-intuitive assertion that needs some
> supporting evidence.  I disagree.  I think large parts of the the
> "communal understanding" live in wetware between human ears and in messy
> procedural code.

I agree. But there is also a huge amount of communal MIS-understanding
that lives in wetware. It is flushed out through the process of
formalization. For instance we all talk about "links" but it is only in
trying to formalize XLink that it became clear that we all used the word
to mean radically different things. 

You can also use UML, set theory or Zen meditation to flush out
misunderstanding but schema writing has the big advantage of providing
immediate, interactive utility. Some customers say: "You mean we have to
go to all of this work to understand our problem domain before we
implement the code? Who has time for that?" The more saavy ones say:
"finally we have an excuse to map our our problem domain without feeling
like we are wasting time drawing pretty pictures."

> >In many areas that *is* cracking
> >the nut.
> 
> Where I work, people aren't satisfied until there's running code that
> does useful stuff, and the schema-ware is an essential but fairly small
> component of getting there.

I often start with two piece of running code and finding the common
language between them *is the problem*. In other cases, of course, the
schema is done before I come in and they want help with the code.

> > As a practical example, consider word processing. By now there
> >are dozens of word processors and desktop publishers. It would be a
> >massive effort to come to understand their commonalities and define the
> >"universal DTP language."
> 
> Huh?  Weren't we talking about schemas? -T.

Sure, we're talking about a schema for the common language between word
processing programs. Once you have such a thing, writing converters into
and out of it is relatively tricky ... its the figuring out the
commonalties between the different models that is the hard (perhaps
impossible) part.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From uche.ogbuji at fourthought.com  Tue Nov  2 16:34:05 1999
From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com)
Date: Mon Jun  7 17:16:28 2004
Subject: A Plea for Schemas 
In-Reply-To: Your message of "Tue, 02 Nov 1999 09:55:59 GMT."
             <Pine.LNX.4.10.9911020944310.2146-100000@localhost.localdomain> 
Message-ID: <199911021644.JAA06093@localhost.localdomain>

Tim Bray:
> > [...]  I think large parts of the the 
> > "communal understanding" live in wetware between human ears and in messy
> > procedural code.

Richard Lanyon:
> Which is why, parenthetically, it's often quite awkward to process XML
> using a declarative, rather than procedural, language.

Eh, what?  This seems a blatant non-sequitur.  The fact that much legacy code 
is procedural is a historical accident and has nothing to do with present and 
future XML-processing.

To some minds, and for some purposes, procedural approaches are awkward: in 
other cases declarative approaches are awkward, but if one had to pick one 
with intrinsically less "awkwardness" for XML-processing, I would argue for 
the declarative approach.

-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From elharo at metalab.unc.edu  Tue Nov  2 16:53:05 1999
From: elharo at metalab.unc.edu (Elliotte Rusty Harold)
Date: Mon Jun  7 17:16:28 2004
Subject: a newbie question
In-Reply-To: <007c01bf24fe$dd96bd80$52138489@bic.nus.edu.sg>
References: <007c01bf24fe$dd96bd80$52138489@bic.nus.edu.sg>
Message-ID: <v04210104b444c2f7b9e3@[168.100.203.234]>

At 2:52 PM +0800 11/2/99, TaNiA wrote:
>Hi all,
>
>I'm totally new to XML and XSL.
>
>I've found sites which explain about what XML and what XSL is, but no where
>have I found a site which shows how to link XSL with XML.
>
>Is there a good site for a comprehensive tutorial for XML that anyone can
>recommend?


Try http://metalab.unc.edu/xml/books/bible/updates/14.html


+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rahulj at us.ibm.com  Tue Nov  2 17:36:25 1999
From: rahulj at us.ibm.com (rahulj@us.ibm.com)
Date: Mon Jun  7 17:16:28 2004
Subject: Some answers for XML4C parser questions...
Message-ID: <8725681D.0060A772.00@d53mta03h.boulder.ibm.com>





The Alphaworks XML4C Discussion forum is a good place to start if you
have questions about XML4C. The URL is:
    http://www.alphaworks.ibm.com/tech/xml4c/



> > The question here is that how to create an XML file "back" from a DOM
> > Tree.  From a discussion i had sometime back on this mailing list I
> > learnt that SUN's JAVA XML parser has an API to write back a DOM tree
> > in an XML file.
> >
> > Does XML4C also has such an API.

> I had the same requirement. I couldn't find a direct API for this
> purpose, but there is some sample code for printing the DOM Tree in
> XML
>  (/xml4csrc2_3_1/samples/DOMPrint/DOMPrint.cpp).
> I could build an API using this code to achieve the purpose.
>
> But I will still like to know, if there is any direct API to achieve
this.

XML4C currently does not provide any direct API to write back the
DOM tree as an XML file. Adding this feature is on our todo list.
As mentioned, DOMPrint is a good starting point.



> On trying to build a small program on HP-UX 11.0, I get the following
> error message
>     /Development/cupert/rahul/icu/lib/libicu-uc.sl
>     No such file or directory
>
> I have put both the library ( libIXXML4C2_3.sl & libicu-uc.sl ) in the
> directory /xml4c2_3_1/lib
>
> and added it to the SHLIB_PATH environment variable.
>
> Why is the path "/Development/cupert/rahul/icu" being assumed ? from
> where is it coming from ?  Is this a bug where a path has been left
> hard coded in the library.  Has anyone encountered this problem
> before?

Reproducing the post from the AlphaWorks XML4C Discussion forum

The path represents the location of the ICU library at build time.
By default the linker stores the location of the external libaries
referenced in the target executable/library.

This in no way should affect your ability to link your applications.
The error message is indicating that you may not have installed the
ICU library or you have not set the SHLIB_PATH to point to the
directory containing the XML4C and the ICU libraries.

Even after setting this environment variable, if you are not able to
link, then we definitely have a problem. Let us know, we will
investigate.

I hope you are using XML4C version 2.3.1 with ICU version 1.2.5.
Let us also know if you are using the binary or the source drop?



> Is it possible to purchase a support agreement on various XML parsers
> available in the market ?
>
> We plan to use IBM's XML4C parser on HP UX. Does IBM give customer
> support for it ?

If you just cannot live without support, then please contact us
at xml4c@us.ibm.com and we will put you in contact with the right
person who will be able to give you details. I am told that support
is quite expensive.


> I tried to get some Y2K compliance statements from the vendors at one
> stage - IBM responded as follows:
>
> "The only official Y2K-certified version of the XML parser available
> through the IBM Websphere at this time is for XML4J".
>
> So you *might* get support for IBM's Java parser if it is purchased as
> part of Websphere (I don't think this applies to the XML4C C++ parser
> though).

This is correct. Websphere only provides support for XML4J and not XML4C.


rahul
rahulj@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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  2 18:41:36 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:28 2004
Subject: A Plea for Schemas
In-Reply-To: Paul Prescod's message of "Tue, 02 Nov 1999 09:15:21 -0600"
References: <3.0.32.19991101223119.00c87b50@pop.intergate.bc.ca> <381F0009.455D7333@prescod.net>
Message-ID: <m31za8pwir.fsf@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> You can also use UML, set theory or Zen meditation to flush out
> misunderstanding but schema writing has the big advantage of
> providing immediate, interactive utility. Some customers say: "You
> mean we have to go to all of this work to understand our problem
> domain before we implement the code? Who has time for that?" The
> more saavy ones say: "finally we have an excuse to map our our
> problem domain without feeling like we are wasting time drawing
> pretty pictures."

Obviously, what works best will depend on the problem and on the
people and personalities involved.  In my experience, formal
specifications (schemas, UML diagrams, etc.) tend to be a serious
distraction early in a large project, because they allow people to
caught up in details far too soon.

Later on during a project's development, object models, data models,
DTDs, and their like can also give the false impression of actually
having accomplished something ("see, here's our object model on this
wall -- just follow it around out into the hall and down past the the
lunchroom") and thus postpone the realization that a project is in
serious danger of being delayed or of failing completely.  It's always
easier to keep spewing out more UML or DTDs than it is actually to
start building a working system.

Formal models do (as Paul says) help to flush out misunderstandings,
but they tend to find misunderstandings over fairly fine details,
which are appropriate to the later stages of a project.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 18:56:58 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:28 2004
Subject: Entities and non-validation
References: <381D2D46.4CBE7A4B@activated.com>
Message-ID: <381F33CE.E30F3408@pacbell.net>

Shawn Silverman wrote:
> 
> How should non-validating parsers handle undeclared:
> 
>         1) Parameter entities in the DTD

If you look at the grammar production, it has only a [VC]
next to it, so this is only a validity error -- which a
nonvalidating processor really ought to ignore, beyond
setting a flag so it ignores all further declarations.


>         2) General entities in the DTD

For refs within entity declarations:  ignore them unless
(and until!) that undeclared entity is later referenced
by expanding the replacement text of the declared entity.
Such an actual reference violates a WFC.

For refs within attribute defaults:  violates one
of the clauses in [WFC: Entity Declared].  But that
WFC violation should be ignored if "standalone='no'"
and (!) the processor didn't read some external PEs.

(I find those two "Entity Declared" clauses to be one
of the most confusing, if not ambiguous, parts of the
whole XML spec.) 


>         3) General entities in the document

Violates a WFC -- fatal error, full stop.


> I like to qualify my question by stating that it is assumed that all of
> these entities are used appropriately, ie. PE's only in the DTD, GE's
> inside attribute values and content, etc.
> 
> I am under the impression that if standalone='no' for the document that
> a non-validating parser can assume that all undeclared entities are
> external.  Is this correct?

If it didn't read those entities, it can assume all sorts of
things going on there, yes.  But if it does read the entities,
then it knows the truth and shouldn't assume otherwise.


> My second question is similar, and comes from section 4.4.3, "Included
> If Validating".
> 
> The first paragraph states that:
> 
> "When an XML processor recognizes a reference to a parsed entity, in
> order to validate the document, the processor must include its
> replacement text. If the entity is external, and the processor is not
> attempting to validate the XML document, the processor may, but need
> not, include the entity's replacement text. If a non-validating parser
> does not include the replacement text, it must inform the application
> that it recognized, but did not read, the entity."
> 
>         1) Obviously, the parser can tell if the entity is external if it has
> previously been declared.  But what if it has't?  What should a
> non-validating parser do?

The simple answer is to stick to non-validating parsers which DO read
all external entities, but that may not be practical.

Otherwise, I'd say the answer is application-specific.  I think
XHTML says things like "render the reference", but that's not
useful for all other applications.


>         2) How does the parser "inform the application" via the SAX interface?
> Is this through the EntityResolver interface?

Good question.  My stance is that SAX2 solves this generically, by
exposing whether _all_ external general entities are included, or not.
And having a lexical callback to indicate the start/end of entities;
the app can have recorded the declarations.

Given that, no per-entity call is needed.  (SAX 1.0 doesn't have any
way to expose this.  Returning null from EntityResolver.resolveEntity
says the parser should use the SYSTEM identifier.)


Those are good questions in some messy areas of XML processing.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 19:09:45 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:28 2004
Subject: Referencing multiple DTD in an XML document
References: <CA25681C.00360FB8.00@d73mta05.au.ibm.com>
Message-ID: <381F36DC.91B73261@pacbell.net>

mparul@in.ibm.com wrote:
> 
> Is it possible to reference two DTD files in the DOCTYPE declaration in an
> XML document?

Absolutely -- just use the right syntax.


First, keep in mind that there are only "external parameter entities".
Too many people talk as if the external subset, as in

	<!DOCTYPE foo SYSTEM "http://www.example.com/uri">

is the DTD ... instead, the whole <!DOCTYPE ...> is the DTD, which
is just a set of declarations.  Don't think of a "DTD file", since
DTDs can consist of many files.


Second, keep in mind that the external subset is only syntactic
sugar, and you can do the same thing without an external subset:

	<!DOCTYPE foo [
	<!ENTITY % foo SYSTEM "http://www.example.com/uri">
	%foo;
	]>

That DTD is semantically equivalent to the first one I showed.


> If not, then how can one use both MathML and say SpeechML tags in an XML
> document.

I presume you want the answer even if you _can reference more than
one external parameter entity?  :-)

It's a simple extension of what I showed above:

	<!DOCTYPE foo [
	<!ENTITY % MathML SYSTEM "http://www.example.com/MathML.dtd">
	%MathML;
	<!ENTITY % SpeechML SYSTEM "http://www.example.com/SpeechML.dtd">
	%SpeechML;
	]>

I'd encourage you to use PUBLIC identifiers as well, so that
local cached copies of those declarations can easily be used.

As has been pointed out, actually combining two DTDs can be a
problem if they happen to use the same element or entity names
for different purposes.  DTD syntax was designed to allow you
to combine sets of declarations designed for that purpose, but
if they weren't so designed ... trouble.  Namespace-aware schemas
may provide solutions in that space, at some point.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 19:20:42 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:28 2004
Subject: XML Client detection
References: <"199911011647346.SM00215"@Unknown>
Message-ID: <381F396D.ABD1AA29@pacbell.net>

rev-bob@gotc.com wrote:
> 
> Does anyone have either (a) a partial list of XML-compliant browser UA
> strings or (b) a suggestion for an alternate approach?

Since your output choices are currently limited to HTML and XHTML, I'd
be sorely tempted to just default to XHTML, and give folk an option to
go to HTML output if that breaks.

The reason is that most reasonably well crafted XHTML will be accepted by
both HTML and XML aware browsers, with the primary known exception being
very old browsers ("version 2") that you may not support anyway.

You only really need XML support in the client if you're trying to use
the XML/CSS (or eventually XML/XSLT) style rendering.  Since I couldn't
use IE5 support for that (no list or link support, or preformatted text),
and Mozilla's not prime-time yet, I'd not bother with that approach for
some time to come.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Tue Nov  2 20:28:42 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:16:28 2004
Subject: A Plea for Schemas 
References: <199911021644.JAA06093@localhost.localdomain>
Message-ID: <002b01bf2571$42a98000$3efbb1cd@tomshp>


From: <uche.ogbuji@fourthought.com>
[many snips...]
>
> To some minds, and for some purposes, procedural approaches are awkward:
in
> other cases declarative approaches are awkward, but if one had to pick one
> with intrinsically less "awkwardness" for XML-processing, I would argue
for
> the declarative approach.
>
> --
 Let us remember, SQL is not procedural, and it is in widespread use.  (Of
course, current SQL is not well suited for hierarchical nesting of many or
an unknown number of levels).

Tom Passin


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



From ypatil at kingston.hummingbird.com  Tue Nov  2 20:41:39 1999
From: ypatil at kingston.hummingbird.com (Yogita Patil)
Date: Mon Jun  7 17:16:28 2004
Subject: Does anybody know why ?
Message-ID: <002501bf2572$975a4c00$1a02060a@andyne.com>

I have 2 seperate functions one that builds the DOM tree and spits out the xml to a text file , the other method reads this xml file in and parses it using the XML4C2 parser and does some magic accordingly. But for some reason it doesn't work , however if the same goes in one method i.e building the DOM tree , spitting out the xml and reading it back in from the created xml file and parsing it ,all in one , it works. Any thoughts on why splitting the reading / writing actions creates trouble for me ? And yes i am initializing the xml4c2 system before using any API in both methods.

Your help is greatly appreciated.
Thanks in advance.

Yogita Patil
Software Developer
Hummingbird Communications Ltd.
Decision Portals Division.
552 Princess Street.
Kingston, Ontario.
K7L-1C7
(613) 548-4355 Ext. 1540

Canada.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991102/3f6bc7af/attachment.htm
From paul at prescod.net  Tue Nov  2 21:30:05 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:28 2004
Subject: XML Client detection
References: <"199911011647346.SM00215"@Unknown> <381F396D.ABD1AA29@pacbell.net>
Message-ID: <381F5784.3F0EF5E9@prescod.net>

David Brownell wrote:
> 
> You only really need XML support in the client if you're trying to use
> the XML/CSS (or eventually XML/XSLT) style rendering.  Since I couldn't
> use IE5 support for that (no list or link support, or preformatted text),
> and Mozilla's not prime-time yet, I'd not bother with that approach for
> some time to come.

Heresy! CSS is the XML stylesheet language that's available and useful
*today*.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From crism at exemplary.net  Tue Nov  2 22:15:51 1999
From: crism at exemplary.net (Christopher R. Maden)
Date: Mon Jun  7 17:16:28 2004
Subject: XML Client detection
Message-ID: <v01530503b4451139d542@[209.157.134.40]>

[Paul Prescod]
>Heresy! CSS is the XML stylesheet language that's available and useful
>*today*.

Unless, of course, you're using MSIE 5 with any entities (such as &lt;), or
any other "major browser" at all.

The truth is that delivering XML to a client (other than careful XHTML) is
still a special case, and probably will be for at least another year.

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  2 23:56:22 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:28 2004
Subject: XML Client detection
In-Reply-To: <v01530503b4451139d542@[209.157.134.40]>
Message-ID: <199911022342.SAA14602@hesketh.net>

At 02:11 PM 11/2/99 -0800, Christopher R. Maden wrote:
>[Paul Prescod]
>>Heresy! CSS is the XML stylesheet language that's available and useful
>>*today*.
>
>Unless, of course, you're using MSIE 5 with any entities (such as &lt;), or
>any other "major browser" at all.

I enjoy the Mozilla builds, but I'll certainly admit that they aren't _yet_
a 'major browser'.

>The truth is that delivering XML to a client (other than careful XHTML) is
>still a special case, and probably will be for at least another year.

Sad but true.  I've been amazed by how incredibly slow (and/or broken)
client-side development for XML has been.

For right now, I'm still telling people to use HTML for Web delivery.  The
CLASS attribute and well-formed can be awfully handy for the conversion
down the line (of both docs and style sheets), but XML on the client is a
tantalizing fantasy for now.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  3 00:37:29 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:29 2004
Subject: A Plea for Schemas
References: <38196183.8B669A0A@praxis.cz> <381E4BC7.72FE@hiwaay.net> <381EBCD2.4155A283@praxis.cz>
Message-ID: <381F8167.2BB1@hiwaay.net>

Matthew Gertner wrote:

> Really interesting stuff. When I first sat down and wrote the
> introduction it was about 10 times longer and contained some of this
> information, but it didn't seem especially relevant in the context of
> pleaing for schemas, so I pared it down to the point where it is mostly
> just a bunch of plausible-sounding lies. 

It's a Jones of mine.  Plausible lies, the speed with 
which the World Wide Web distributes them and the 
tendancy of the press and the similarly ignoble 
readers of these lists to believe that nothing without 
a URL is worth checking, make the WWW do precisely what 
it was not designed to do:  devolve knowledge.   In 
about a hundred years, they will burn the W3C founders 
in effigy on the lawns at was once the hallowed 
halls of MIT, but will then be a museum for the 
slow and largely irrelevant who can't master 
surfing in virtual hypercube.  They won't burn 
them for malice; they will do it for pleasure 
because burning their heritage has been equated 
with good memory management. 

While it is a lot like a monkey putting the 
plug back into the elephant, I am learning to 
accept being tied to the elephant's tail. I will 
never learn to like it.

Hmm... this humor thing might be worth learning... nah.

> Ouch. Whatever happened to poetic license? I thought "a hobbled subset
> of SGML" sounded snappier than "an SGML application specifying a
> vocabulary for the transfer and display of hypertext documents". The
> latter would also have detracted from the humorous value of the
> paragraph, of which there is hopefully at least some.

See above.  The problem is, they quote you and when 
they do that often enough, the universe gets a little 
colder.

> > Tell 'em, "ahh, XML Works.  We just don't agree on how."
> 
> Seems like a healthy state of affairs. If we keep churning the idea
> bucket the One True Way will eventually become obvious.

No one true way;  just a bag of tools and maps with lots 
of roads to the same place.  Look at DTDs as 
view dimensions and aggregate them using OLAP tools. 
Then decide where you want to go.  That's one approach.

A DTD is the backside of a stored query.  :-)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From RSridhar at CBSINC.COM  Wed Nov  3 00:42:47 1999
From: RSridhar at CBSINC.COM (RANGANATHAN Sridhar)
Date: Mon Jun  7 17:16:29 2004
Subject: XML Convert 1.1 - Attributes and Element
Message-ID: <A450FADB8CF3D211BD1300902740ABEE222A58@CAEX01>

Hello Everyone,

I have a question with XML Convert in creating a XML document from flat
file.

The input flat file record structure is:

F1 F2  F3

I want to create an XML document with the following structure:

<employee attribute1= "F1" attribute2="F2">F3</employee>

With my limited knowledge of XML Convert I am able to convert to the
following
structure.

<employee attribute1= "F1" attribute2="F2">
  <newfld>F3</newfld>
</employee>

If anyone has accomplished this with XML Convert please share with me.

Thanks.
Sridhar.




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



From rev-bob at gotc.com  Wed Nov  3 01:55:44 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:29 2004
Subject: XML Client detection
Message-ID: <199911022042322.SM00159@Unknown.>

> Since your output choices are currently limited to HTML and XHTML, I'd
> be sorely tempted to just default to XHTML, and give folk an option to
> go to HTML output if that breaks.
> 
> The reason is that most reasonably well crafted XHTML will be accepted by
> both HTML and XML aware browsers, with the primary known exception being
> very old browsers ("version 2") that you may not support anyway.

The trouble with that is, I kind of make a crusade out of accessibility.  Just about 
anybody can access my HTML, because I've taken care to include several legacy 
support tricks (such as a SCRIPT element inside a NOSCRIPT element, which is 
specifically designed to work around the fact that NN2 doesn't know what NOSCRIPT 
means) which are spec-illegal yet necessary for old-client support.

With the XHTML pages, I'm trying to get away from that.  Since old browsers don't 
understand XML, I can drop a lot of the antiquated hacks and make the XHTML code a 
bit cleaner.  Hence, the need for a client sniffer - send the older browsers to the HTML 
code which makes allowances for them, and shamelessly take advantage of the XML-
compliant browsers' features.
 
> You only really need XML support in the client if you're trying to use
> the XML/CSS (or eventually XML/XSLT) style rendering.  Since I couldn't
> use IE5 support for that (no list or link support, or preformatted text),
> and Mozilla's not prime-time yet, I'd not bother with that approach for
> some time to come.

Look at it this way.  If I get the sniffer working, I can do things like morph FONT FACE 
tags into CSS styles for the XHTML version, thus ultimately bringing the XHTML 
version several steps closer to the ideal of divorcing content from presentation.  That's 
my goal; I'm not looking for XML support because I need it, but because excluding 
browsers without it will let me get closer to "pure code" in those pages.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 03:14:21 1999
From: boblyons at unidex.com (Robert C. Lyons)
Date: Mon Jun  7 17:16:29 2004
Subject: XML Convert 1.1 - Attributes and Element
In-Reply-To: <A450FADB8CF3D211BD1300902740ABEE222A58@CAEX01>
Message-ID: <000001bf25a9$40bafc00$62c80318@etntwn1.nj.home.com>

Sridhar writes:
> ... I want to create an XML document with the following structure:
> 
> <employee attribute1= "F1" attribute2="F2">F3</employee>
> 
> With my limited knowledge of XML Convert I am able to convert to the
> following structure.
> 
> <employee attribute1= "F1" attribute2="F2">
>   <newfld>F3</newfld>
> </employee>
> 
> If anyone has accomplished this with XML Convert please share with me.
> 

Sridhar,

XML Convert 1.1 can not do this.
I may add this capability to a future version
of XML Convert, since you are not the first 
person to ask for this.

Currently, the XFlat language
does not allow you to map a field value
to the PCDATA content of the element to 
which the record maps.

You can use an XSLT processor (e.g., Jame Clark's XT)
and the following simple stylesheet to transform the
2nd XML document above into the desired XML document:

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
		version="1.0">
    <xsl:template match="newfld">
       <xsl:value-of select="."/>
    </xsl:template>
    <xsl:template match="@*|*">
        <xsl:copy>
            <xsl:apply-templates select="@*|*"/>
        </xsl:copy>
    </xsl:template>
</xsl:stylesheet>

Hope this helps.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Wed Nov  3 03:17:50 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:29 2004
Subject: XML Client detection
Message-ID: <19991102210003.SM00159@neoplanet.com>

> >The truth is that delivering XML to a client (other than careful XHTML) is
> >still a special case, and probably will be for at least another year.
> 
> Sad but true.  I've been amazed by how incredibly slow (and/or broken)
> client-side development for XML has been.

It's PNG all over again.  When was that spec ratified, 1996?  And yet, IE5 still doesn't 
claim to handle it.  (See my earlier message concerning HTTP_ACCEPT.)  At least 
Netscape's on the wagon with that....
 
> For right now, I'm still telling people to use HTML for Web delivery.  The
> CLASS attribute and well-formed can be awfully handy for the conversion
> down the line (of both docs and style sheets), but XML on the client is a
> tantalizing fantasy for now.

Hey, that's why I'm starting my conversion work now.  There's this nifty little program 
called htp (html pre-processor, at http://www.crl.com/~jnelson/htp/) floating about that, 
if used imaginatively, can let you set up two sets of definitions which can be used on the 
same batch of data files to generate HTML on the one hand and XHTML (perhaps, 
eventually, XML) on the other.  That's what I've been doing, and so far it works very 
well.  I still have a way to go before I get to my destination, but by starting now, I don't 
have to rush.  As things currently stand, all my architecture is in place - I've got one set 
of common definitions, one set of HTML-only definitions, and one set of XML-only 
definitions.  HTML-only plus common yields HTML files; XML-only plus common 
yields XHTML.  So far, I've used this primarily for stripping out legacy support on the 
XML side and for converting the !DOCTYPE statements, but with some tinkering, it can 
go a lot further.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jamesr at steptwo.com.au  Wed Nov  3 03:41:32 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:16:29 2004
Subject: XML Convert 1.1 - Attributes and Element
In-Reply-To: <A450FADB8CF3D211BD1300902740ABEE222A58@CAEX01>
Message-ID: <4.2.0.58.19991103143229.00c8da00@203.41.126.17>

At 11:36 3/11/1999 , RANGANATHAN Sridhar wrote:

>Hello Everyone,
>
>I have a question with XML Convert in creating a XML document from flat
>file.
>
>The input flat file record structure is:
>
>F1 F2  F3
>
>I want to create an XML document with the following structure:
>
><employee attribute1= "F1" attribute2="F2">F3</employee>
>
>With my limited knowledge of XML Convert I am able to convert to the
>following
>structure.
>
><employee attribute1= "F1" attribute2="F2">
>   <newfld>F3</newfld>
></employee>
>
>If anyone has accomplished this with XML Convert please share with me.

I don't know anything about XML Convert, but
here's the Omnimark commands you need to achieve this:

FIND [ANY EXCEPT WHITE-SPACE]+ => F1
         [ANY EXCEPT WHITE-SPACE]+ => F2
         ANY-TEXT+ => F3 "%n"

         OUTPUT "<employee attribute1='" || F1
                 || "' attribute2='" || F2
                 || "'>" || F3
                 || "</employee>"

(Note: this has not been tested!)

A Perl script would also get the job done.

Hope this helps,

J


-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  3 05:02:38 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:29 2004
Subject: A Plea for Schemas
Message-ID: <005801bf25bb$f5af9460$1cf96d8c@NT.JELLIFFE.COM.AU>

 From: Tim Bray <tbray@textuality.com>

>Where I work, people aren't satisfied until there's running code that
>does useful stuff, and the schema-ware is an essential but fairly small
>component of getting there.

One of my hopes for new schema languages (especially those using XML
element syntax) is that, like any data with generic markup, there may be
useful and unexpected applications made possible.  The Xeena people were
nicely surpised that a DTD could be used to generate a structure-editor:
a better schema language will allow better such editors.

Already there is a spread of reasonable opinions on schemas:
    * they need to integrate into existing systems as much as possible
(the XML Schema approach?); or
    * they only need to provide information that generating and
receiving software do not already have (the SGML DTD approach?);
    * they need to be as complete as possible (the EXPRESS approach?);
or
    * they need to be simple and elegant (the XML DTD approach?);

A schema that provides enough information becomes useful as a
declarative programming tool. (For example, I have a working Schematron
that generates RDF based on tree-patterns: it is an automated external
markup tool, yet it is driven by a schema.)

Tim is of course correct that a schema is only part of the whole
picture, but a schema language can be judged on how readily it allows
useful systems and tools to be built.  That being so, it may be a strong
schema system is one which has some 'use' information as well as the
"pure" schemas: documentation, forms building, validation, style, etc.:
where the type information from the schema can directly be used for some
purpose.

DTDs provide simple stucture models but also have infoset contributions
with #FIXED attributes and default attribute values (i.e., a simple
transformation of the instance). This makes them 'impure' as a schema
language, but undoubtedly more useful.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From XMLDevGuy at aol.com  Wed Nov  3 05:11:59 1999
From: XMLDevGuy at aol.com (XMLDevGuy@aol.com)
Date: Mon Jun  7 17:16:29 2004
Subject: !Updating XML Files!
Message-ID: <0.724fa0af.25511dac@aol.com>

Hi,

First time posting.  New to the list.

Ive been using XML and servlets and using SAX to parse information and using 
IBM's XML tools for DTD which help.

I have one major question and I wanted to see how the pro's do it ;-)  How do 
you update your XML files?  Example:

<Entry>
<Name>Jon
</Entry>

If I wanted to add another entry what is the easiest way to do it (is there 
anything besides constructing the full DOM tree every time?)

Are there anything like this:

XMLFile file = new XMLFile("file.xml");
file.add("Entry", "Jane");

?  

Thanks.

- Jon

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 10:54:18 1999
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:16:29 2004
Subject: public identifiers [Re: Referencing multiple DTD in an XML document]
References: <CA25681C.00360FB8.00@d73mta05.au.ibm.com> <381F36DC.91B73261@pacbell.net>
Message-ID: <3820142B.B9C1BF27@mecomnet.de>

greetings;

David Brownell wrote:
> 
> ...
> 
> It's a simple extension of what I showed above:
> 
>         <!DOCTYPE foo [
>         <!ENTITY % MathML SYSTEM "http://www.example.com/MathML.dtd">
>         %MathML;
>         <!ENTITY % SpeechML SYSTEM "http://www.example.com/SpeechML.dtd">
>         %SpeechML;
>         ]>
> 
> I'd encourage you to use PUBLIC identifiers as well, so that
> local cached copies of those declarations can easily be used.
> 

Could someone expound further on this statement?

I recall only that the rec says something about permitting a processor to use
the public identifier to generate an alternative URI to the system identifier
to be used to retrieve an external resource.
Is the "customary usage", in fact, that processors use the public identifier
to name an entry in a local and/or process-specific cache? which they manage dynamically?

I wonder this also because I've yet to see a conclusive discussion of whether
dtd's (or for that matter schema) in the namespace age are stable. That is,
whether the same system uri will always identify an identical dtd/schema.

For example, would a processor be conforming if it were to, upon not finding a
resource "under" a public identifier, retrieve and expand the resource located
through the system identifier and cache the expanded (or even decoded result)
"under" the public identifier?

?


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



From antons at epos.co.za  Wed Nov  3 11:43:50 1999
From: antons at epos.co.za (Anton Schoultz - ePOS)
Date: Mon Jun  7 17:16:29 2004
Subject: XSL
Message-ID: <NBBBLIPEHIMMNAPFNOLCCEKBEBAA.antons@epos.co.za>

Hi all,
Yet another idiot question..
I have found lots of info on XML, and lots on XSL, but very little on
combining them!

Hypothetical case; let's say that I have a servlet (eg Java) runing which
accepts an HTTP POST/GET to query a product catalogue. The servlet queries a
database and then generates an XML document such as this..


<?xml version="1.0"?>
<!DOCTYPE ProdList SYSTEM "http://www.acme.com/dtd/ProdList.dtd">
<ProdList>
 <hdr date="19991201">
  <title>Catalogue as of 1st December</title>
 </hdr>
 <prod code="101" short="keyboard" price="50.00">Qwerky keyboard</prod>
 <prod code="MS1" short="Mouse" price="5.00">Mickey Mouse</prod>
 <prod code="CRT2" short="Monitor" price="100.00">Monitor Lizard</prod>
</ProdList>


Let's say we have a DTD available on the web server
"www.acme.com/dtd/ProdList.dtd"
which looks like this..

<!ELEMENT ProdList ( hdr, prod* ) >
  <!-- header specifies effective date -->
  <!ELEMENT hdr ( title? ) >
  <!ATTLIST hdr
    date CDATA #IMPLIED
  >
  <!ELEMENT title (#PCDATA)* >
  <!-- each product has a code, short-descripiton and a price. -->
  <!-- the data holds full description -->
  <!ELEMENT prod (#PCDATA)* >
  <!ATTLIST prod
    code  CDATA #REQUIRED
    short CDATA #IMPLIED
    price CDATA #IMPLIED
  >
>

Let's say that a style sheet is also available on www.acme... to ouput the
catalogue as an HTML table, looks like this ... (which probably has lots of
errors!)

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org.TR/WD-xsl">
  <xsl:template match="/">
    <HTML>
      <HEAD>
        <TITLE>
         <xsl:for-each select="hdr">
           <xsl:value-of select="."/>
         </xsl:for-each>
        </TITLE>
      </HEAD>
      <BODY BGCOLOR="#808080">
        <H1>Product List</H1>
        <TABLE BORDER="1" WIDTH="400">
          <TR>
            <TH>Stock Code</TH>
            <TH>Short Description</TH>
            <TH>Long Description</TH>
            <TH>Unit Price</TH>
          </TR>
          <xsl:for-each select="ProdList/prod">
            <TR>
              <TD> <xsl:value-of select="@code"/>  </TD>
              <TD> <xsl:value-of select="@short"/> </TD>
              <TD> <xsl:value-of select="."/>      </TD>
              <TD> <xsl:value-of select="@price"/> </TD>
            </TR>
          </xsl:for-each>
        </TABLE>
      </BODY>
    </HTML>
  </xsl:template>
</xsl:stylesheet>



How should the servlet change it's ouput (text/xml?) so that the browser (eg
IE5) will pick-up the XSL and format the xml output into the desired HTML
table ?
What changes are required to the above files ?

Regards

Anton Schoultz
e-mail: mailto:antons@ePOS.co.za
Office: +27 11 807-9400 Ext. 205


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  3 13:23:10 1999
From: nicmila at vscht.cz (Miloslav Nic)
Date: Mon Jun  7 17:16:29 2004
Subject: Schematron validation based on the contents of another file!
Message-ID: <382036A4.C2F76825@vscht.cz>

I have added two more examples to Schematron tutorial at:
http://zvon.vscht.cz/HTMLonly/SchematronTutorial/General/contents.html

I have just realized, that Schematron engines  based on XSLT can use
XSLT function: document() to perform this type of validation.

Example 18
A paragraph in XML 2 can only start with words specified in XML 1 (file
source1.xml)

Example 17
XML 1 (file source1.xml) contains a list of authors. These authors are
referred to in XML 2. The Schematron checks if for each referred author
in XML 2 exists an entry in XML 1.
-- 
***************************************************************
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  
****************************************************************
Support free information exchange: http://zvon.vscht.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From vlashua at RSGsystems.com  Wed Nov  3 14:16:35 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:30 2004
Subject: XSL
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9C80@MAILPROD>

add the following after the <?xml version="1.0"> line

<?xml-stylesheet type="text/xsl" href="[yourxslURL]"?>

Make a header for the stylesheet like this:

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"
 xmlns="http://www.w3.org/TR/REC-html40" result-ns=""
 language="JScript"> 

Vane

-----Original Message-----
From: Anton Schoultz - ePOS [mailto:antons@epos.co.za]
Sent: Wednesday, November 03, 1999 6:41 AM
To: XML-DEV LIST
Subject: XSL


Hi all,
Yet another idiot question..
I have found lots of info on XML, and lots on XSL, but very little on
combining them!

Hypothetical case; let's say that I have a servlet (eg Java) runing which
accepts an HTTP POST/GET to query a product catalogue. The servlet queries a
database and then generates an XML document such as this..


<?xml version="1.0"?>
<!DOCTYPE ProdList SYSTEM "http://www.acme.com/dtd/ProdList.dtd">
<ProdList>
 <hdr date="19991201">
  <title>Catalogue as of 1st December</title>
 </hdr>
 <prod code="101" short="keyboard" price="50.00">Qwerky keyboard</prod>
 <prod code="MS1" short="Mouse" price="5.00">Mickey Mouse</prod>
 <prod code="CRT2" short="Monitor" price="100.00">Monitor Lizard</prod>
</ProdList>


Let's say we have a DTD available on the web server
"www.acme.com/dtd/ProdList.dtd"
which looks like this..

<!ELEMENT ProdList ( hdr, prod* ) >
  <!-- header specifies effective date -->
  <!ELEMENT hdr ( title? ) >
  <!ATTLIST hdr
    date CDATA #IMPLIED
  >
  <!ELEMENT title (#PCDATA)* >
  <!-- each product has a code, short-descripiton and a price. -->
  <!-- the data holds full description -->
  <!ELEMENT prod (#PCDATA)* >
  <!ATTLIST prod
    code  CDATA #REQUIRED
    short CDATA #IMPLIED
    price CDATA #IMPLIED
  >
>

Let's say that a style sheet is also available on www.acme... to ouput the
catalogue as an HTML table, looks like this ... (which probably has lots of
errors!)

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org.TR/WD-xsl">
  <xsl:template match="/">
    <HTML>
      <HEAD>
        <TITLE>
         <xsl:for-each select="hdr">
           <xsl:value-of select="."/>
         </xsl:for-each>
        </TITLE>
      </HEAD>
      <BODY BGCOLOR="#808080">
        <H1>Product List</H1>
        <TABLE BORDER="1" WIDTH="400">
          <TR>
            <TH>Stock Code</TH>
            <TH>Short Description</TH>
            <TH>Long Description</TH>
            <TH>Unit Price</TH>
          </TR>
          <xsl:for-each select="ProdList/prod">
            <TR>
              <TD> <xsl:value-of select="@code"/>  </TD>
              <TD> <xsl:value-of select="@short"/> </TD>
              <TD> <xsl:value-of select="."/>      </TD>
              <TD> <xsl:value-of select="@price"/> </TD>
            </TR>
          </xsl:for-each>
        </TABLE>
      </BODY>
    </HTML>
  </xsl:template>
</xsl:stylesheet>



How should the servlet change it's ouput (text/xml?) so that the browser (eg
IE5) will pick-up the XSL and format the xml output into the desired HTML
table ?
What changes are required to the above files ?

Regards

Anton Schoultz
e-mail: mailto:antons@ePOS.co.za
Office: +27 11 807-9400 Ext. 205


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



From gorden at bnl.gov  Wed Nov  3 14:43:04 1999
From: gorden at bnl.gov (Gorden-Ozgul, Patricia E)
Date: Mon Jun  7 17:16:30 2004
Subject: Newbie - How to Load XML data into Oracle
Message-ID: <698DB793D712D31180B600902746422D84757E@exchange01.bnl.gov>

I'm new to the world of SGML (not new) and XML (new) and document
processing.  I am an Oracle developer/DBA.

My understanding of the my part of the project is to load the XML data into
an Oracle database (8.x on Solaris 2.6) from which we will be creating XML
for a required data call.  The XML output will be 'passed' through multiple
DTDs based upon which type of document is represented. 

I have never worked with variable length, multiple line tagged data before.
Is anyone out there familiar with the method by which I could perform such a
load?  It looks to me like Oracle's load utility, SQL*LOADER couldn't handle
this.  To use it I'd need to convert the XML data to a delimited flat file.

Does anyone out there have any suggestions or help for me?
TIA 

* * * * *
Pat Gorden-Ozgul
Database Development
Information Services Division Bldg 477
Brookhaven National Laboratory
Upton, New York   11967
(516)344-5159     gorden@bnl.gov

I take sole responsibility for any opinion expressed herein.
* * * * *

	

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



From Cem.Redif at Xpedior.com  Wed Nov  3 15:50:53 1999
From: Cem.Redif at Xpedior.com (Cem Redif)
Date: Mon Jun  7 17:16:30 2004
Subject: Joined today: Newbie questions
Message-ID: <3820C9EA.CE0B83E@Xpedior.com>

Hi All,

I am very new to XML and I would like to get starting as soon as
possible.  I have some very simple questions to ask:

1. Does Netscape and IE support XML automatically?
2. What plug-ins do I need (if any) for Netscape and IE for building
simple applications?
3. What does the XML Parser do?  Does it translate XML code into HTML?
4. Do I need XSL or CSS?  What is their purpose?
5. What other components do I need to get started - that is to build a
simple application?

Thanks,
Cem.


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



From tpassin at mitretek.org  Wed Nov  3 16:06:31 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:16:30 2004
Subject: XSL
Message-ID: <005801bf2614$d66afb40$38a3f1ce@ls-.mitretek.org>




From: Anton Schoultz - ePOS <antons@epos.co.za>


>Hi all,
>Yet another idiot question..
>I have found lots of info on XML, and lots on XSL, but very little on
>combining them!
>
>Hypothetical case; let's say that I have a servlet (eg Java) runing which
>accepts an HTTP POST/GET to query a product catalogue. The servlet queries a
>database and then generates an XML document such as this..
>
>
><?xml version="1.0"?>
><!DOCTYPE ProdList SYSTEM "http://www.acme.com/dtd/ProdList.dtd">
><ProdList>
> <hdr date="19991201">
>  <title>Catalogue as of 1st December</title>
> </hdr>
> <prod code="101" short="keyboard" price="50.00">Qwerky keyboard</prod>
> <prod code="MS1" short="Mouse" price="5.00">Mickey Mouse</prod>
> <prod code="CRT2" short="Monitor" price="100.00">Monitor Lizard</prod>
></ProdList>
>
>
>Let's say we have a DTD available on the web server
>"www.acme.com/dtd/ProdList.dtd"
>which looks like this..
>
><!ELEMENT ProdList ( hdr, prod* ) >
>  <!-- header specifies effective date -->
>  <!ELEMENT hdr ( title? ) >
>  <!ATTLIST hdr
>    date CDATA #IMPLIED
>  >
>  <!ELEMENT title (#PCDATA)* >
>  <!-- each product has a code, short-descripiton and a price. -->
>  <!-- the data holds full description -->
>  <!ELEMENT prod (#PCDATA)* >
>  <!ATTLIST prod
>    code  CDATA #REQUIRED
>    short CDATA #IMPLIED
>    price CDATA #IMPLIED
>  >
>>
>
>Let's say that a style sheet is also available on www.acme... to ouput the
>catalogue as an HTML table, looks like this ... (which probably has lots of
>errors!)
>
><?xml version="1.0"?>
><xsl:stylesheet xmlns:xsl="http://www.w3.org.TR/WD-xsl">
>  <xsl:template match="/">
>    <HTML>
>      <HEAD>
>        <TITLE>
>         <xsl:for-each select="hdr">
>           <xsl:value-of select="."/>
>         </xsl:for-each>
>        </TITLE>
>      </HEAD>
>      <BODY BGCOLOR="#808080">
>        <H1>Product List</H1>
>        <TABLE BORDER="1" WIDTH="400">
>          <TR>
>            <TH>Stock Code</TH>
>            <TH>Short Description</TH>
>            <TH>Long Description</TH>
>            <TH>Unit Price</TH>
>          </TR>
>          <xsl:for-each select="ProdList/prod">
>            <TR>
>              <TD> <xsl:value-of select="@code"/>  </TD>
>              <TD> <xsl:value-of select="@short"/> </TD>
>              <TD> <xsl:value-of select="."/>      </TD>
>              <TD> <xsl:value-of select="@price"/> </TD>
>            </TR>
>          </xsl:for-each>
>        </TABLE>
>      </BODY>
>    </HTML>
>  </xsl:template>
></xsl:stylesheet>
>
>
>
>How should the servlet change it's ouput (text/xml?) so that the browser (eg
>IE5) will pick-up the XSL and format the xml output into the desired HTML
>table ?
>What changes are required to the above files ?


Why not have the servelet just return the transformed html, as long as you are
running a servelet anyway?

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 17:18:48 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:16:30 2004
Subject: Joined today: Newbie questions
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F278073@MDYNYCMSX1>

In general, the xml-l list is better for basic XML issues; xml-dev
concentrates on more advanced and theoretical stuff. See
http://www.oasis-open.org/cover/lists.html#XML-L for more on xml-l. See also
the XML FAQ at http://www.ucc.ie/xml/ and good introductions for newcomers
at http://www.xmlinfo.com/newcomers/.

>1. Does Netscape and IE support XML automatically?

IE5 does, Netscape 4 doesn't. XML support is part of Mozilla, the version of
Netscape under development.

>2. What plug-ins do I need (if any) for Netscape and IE for building
>simple applications?

I don't know of any plugins that would make for a different answer in 1.
above.

>3. What does the XML Parser do?  Does it translate XML code into HTML?

It checks the well-formedness and optionally the validity of an XML
document. Typically, it also reads the document's components into data
structures or triggers function calls that let an application use those
components. Conversion to HTML could be one such application.

>4. Do I need XSL or CSS?  What is their purpose?

They are two stylesheet standards that let you specify the appearance of
different elements in your document.

>5. What other components do I need to get started - that is to build a
>simple application?

XML is used for a wide variety of applications, so there's no simple answer
to this question.

Bob DuCharme       www.snee.com/bob       <bob@  
snee.com>  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  3 17:28:30 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:30 2004
Subject: Schematron validation based on the contents of another file!
Message-ID: <000c01bf2624$0ef6b2b0$47f96d8c@NT.JELLIFFE.COM.AU>

Wow, that is a great find. I think it allows us to have external
controlled vocabularies, but ones where we don't care on the DTD that
that vocabulary is stored in: by having smarter links (i.e, Xpaths) we
can locate particular fields in the remote document regardless of the
element names used.

Rick Jelliffe

-----Original Message-----
From: Miloslav Nic <nicmila@vscht.cz>
To: xsl-list <xsl-list@mulberrytech.com>; xml-dev@ic.ac.uk
<xml-dev@ic.ac.uk>
Date: Wednesday, 3 November 1999 21:51
Subject: Schematron validation based on the contents of another file!


>I have added two more examples to Schematron tutorial at:
>http://zvon.vscht.cz/HTMLonly/SchematronTutorial/General/contents.html
>
>I have just realized, that Schematron engines  based on XSLT can use
>XSLT function: document() to perform this type of validation.
>
>Example 18
>A paragraph in XML 2 can only start with words specified in XML 1 (file
>source1.xml)
>
>Example 17
>XML 1 (file source1.xml) contains a list of authors. These authors are
>referred to in XML 2. The Schematron checks if for each referred author
>in XML 2 exists an entry in XML 1.
>--
>***************************************************************
>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
>****************************************************************
>Support free information exchange: http://zvon.vscht.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 17:36:10 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:30 2004
Subject: Entities and non-validation
References: <381D2D46.4CBE7A4B@activated.com> <381F33CE.E30F3408@pacbell.net> <381F4A76.7F91ACBC@goshawk.com>
Message-ID: <38207267.B2D1BE88@pacbell.net>

Good catch.

When the nonvalidating parser ignored one or more external PEs,
this isn't a fatal error.  SAX2 (alpha still) has ways to report
the situation, as I noted elsewhere in my response.

My general advice is still to avoid nonvalidating parsers that
don't read external entities, since the failure modes get so
confusing.

- Dave


Steve Dahl wrote:
> 
> David Brownell wrote:
> 
> > >         3) General entities in the document
> >
> > Violates a WFC -- fatal error, full stop.
> 
> No. If the parser has failed to read part of the external subset of the DTD (because it is not
> validating), an undeclared entity reference in the document content is not a fatal error. The
> fatal error, full stop, only occurs if you are certain that you've read the entire DTD, and
> still have not encountered a declaration for the named entity.
> 
> So, if the entity is undeclared, and it's not a fatal error, what should you do?
> 
> --
> - Steve Dahl
> sdahl@goshawk.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From smuench at us.oracle.com  Wed Nov  3 18:24:56 1999
From: smuench at us.oracle.com (Steve Muench)
Date: Mon Jun  7 17:16:30 2004
Subject: Schematron validation based on the contents of another file!
References: <000c01bf2624$0ef6b2b0$47f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <009f01bf2628$43734b80$54561990@us.oracle.com>

Another simple corollary is that since:

  document()

can take a uri, that uri can be a URL and that URL
can resolve to a server that delivers schema rules
out of a runtime database dictionary.

The would let you write validations, for example,
in a schema representing an airline reservation
that a <DepartureAirport> must be one of
the 9000+ valid three-letter airport codes, but
no other three-letter combination.

You certainly don't want to parse an XML file
with the 9000 codes in it to find it the airport
code "XML" is a valid one, so you can setup
a server-side, URL-accessible "XML Data Service"
that tells you the answer by looking in a database,
returning the answer to you in a little "datagram"
of XML, via the "document()" function in XSLT.

Here's roughly how you could do it...

By installing the Oracle XSQL Servlet (or similar
server-side assistant for combining SQL/XML/XSLT)
and writing a server-side query like:

  <query rowset-element="AIRPORTS" row-element="AIRPORT">
     SELECT description, code
           FROM all_airport_codes
        WHERE code = UPPER('{@code}'
  </query>

Then a URL like:

    http://iata.org/airport-check.xsql?code=XML

Will return an XML document like:
<?xml version = '1.0'?>
<AIRPORTS>
   <AIRPORT num="1">
      <CODE>XML</CODE>
      <DESCRIPTION>Minlaton, Sa, Australia</DESCRIPTION>
   </AIRPORT>
</AIRPORTS>

You can use the:


select="document(concat('http://iata.org/airport-check.xsql?code=',.)/AIRPOR
TS/AIRPORT"

to check if the code was found...

________________________________________________________
Steve Muench, BC4J Development Team & XML Evangelist
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: Rick Jelliffe <ricko@allette.com.au>
To: <xml-dev@ic.ac.uk>
Sent: Wednesday, November 03, 1999 9:51 AM
Subject: Re: Schematron validation based on the contents of another file!


| Wow, that is a great find. I think it allows us to have external
| controlled vocabularies, but ones where we don't care on the DTD that
| that vocabulary is stored in: by having smarter links (i.e, Xpaths) we
| can locate particular fields in the remote document regardless of the
| element names used.
|
| Rick Jelliffe
|
| -----Original Message-----
| From: Miloslav Nic <nicmila@vscht.cz>
| To: xsl-list <xsl-list@mulberrytech.com>; xml-dev@ic.ac.uk
| <xml-dev@ic.ac.uk>
| Date: Wednesday, 3 November 1999 21:51
| Subject: Schematron validation based on the contents of another file!
|
|
| >I have added two more examples to Schematron tutorial at:
| >http://zvon.vscht.cz/HTMLonly/SchematronTutorial/General/contents.html
| >
| >I have just realized, that Schematron engines  based on XSLT can use
| >XSLT function: document() to perform this type of validation.
| >
| >Example 18
| >A paragraph in XML 2 can only start with words specified in XML 1 (file
| >source1.xml)
| >
| >Example 17
| >XML 1 (file source1.xml) contains a list of authors. These authors are
| >referred to in XML 2. The Schematron checks if for each referred author
| >in XML 2 exists an entry in XML 1.
| >--
| >***************************************************************
| >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
| >****************************************************************
| >Support free information exchange: http://zvon.vscht.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
| >unsubscribe xml-dev
| >To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
| unsubscribe xml-dev
| To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 18:31:14 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:30 2004
Subject: public identifiers [Re: Referencing multiple DTD in an XML document]
References: <CA25681C.00360FB8.00@d73mta05.au.ibm.com>
	 <381F36DC.91B73261@pacbell.net> <3820142B.B9C1BF27@mecomnet.de>
Message-ID: <38207C43.E8F887DA@pacbell.net>

james anderson wrote:
> 
> greetings;
> 
> David Brownell wrote:
> >
> > ...
> >
> > It's a simple extension of what I showed above:
> >
> >         <!DOCTYPE foo [
> >         <!ENTITY % MathML SYSTEM "http://www.example.com/MathML.dtd">
> >         %MathML;
> >         <!ENTITY % SpeechML SYSTEM "http://www.example.com/SpeechML.dtd">
> >         %SpeechML;
> >         ]>
> >
> > I'd encourage you to use PUBLIC identifiers as well, so that
> > local cached copies of those declarations can easily be used.
> >
> 
> Could someone expound further on this statement?

I'll give my understanding, which AFIAK isn't radical.


> I recall only that the rec says something about permitting a processor to use
> the public identifier to generate an alternative URI to the system identifier
> to be used to retrieve an external resource.

Right.


> Is the "customary usage", in fact, that processors use the public identifier
> to name an entry in a local and/or process-specific cache?

Now you're getting into cache management policies.  Lots of
them are possible.  Pick the best one for your application
or your site -- key advice for any cache, not just XML.


>	 which they manage dynamically?

I've normally seen this be static ... the way to do this dynamically
is to have the XML parser talk to a caching HTTP proxy server, so that
you're re-using existing infrastructure.

The downside of dynamically caching these is epitomized by me using my
laptop in a cafe, without a wireless modem:  no network.  So it's
desirable to have some sort of static catalog describing the local
cache.  I do that when validating XHTML, for example.

Hence the word "easy" in my quote above:  easy to set up a
manually administered cache, with a catalog.  More complex
schemes are also possible, just less easy (except for use
of a caching HTTP proxy server, which only works for one
class of system URIs).


> I wonder this also because I've yet to see a conclusive discussion of whether
> dtd's (or for that matter schema) in the namespace age are stable. That is,
> whether the same system uri will always identify an identical dtd/schema.

Depends on the URI and how it's managed.  As a rule of thumb, I
never assume that any identifier will always identify the same
thing ... serves me quite well.  Some folk would like to arrange
that URNs always identify an "identical" resource though.


> For example, would a processor be conforming if it were to, upon not finding a
> resource "under" a public identifier, retrieve and expand the resource located
> through the system identifier and cache the expanded (or even decoded result)
> "under" the public identifier?

I don't think you'll find a conformance requirement for cache
management policies.  Two things to watch out for though:

    -	XML doesn't define the namespace for PUBLIC identifiers.
	(I understand SGML did.)  So two different folk could easily
	assign different meanings to a public ID like "foo".  If you
	choose to dynamically manage a cache, you may want a heuristic
	to make it apply only to SGML FPIs or to URNs.

    -	Watch out for conditional sections, since you may need to
	deal with two different documents that INCLUDE or IGNORE
	different chunks of an external PE.  (If you just cache
	unparsed data bytes you should be safe.)

I was using the word "cache" in a broad sense.   Also, using the
existence of a PUBLIC identifier as a flag that the content in
question is intended to fit into some such "cached" usage model.
(Else, why use that syntax?)

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 18:52:10 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:30 2004
Subject: XML Client detection
References: <"199911022042322.SM00159"@Unknown>
Message-ID: <38208125.7B550C27@pacbell.net>

In short, you can't just assume XHTML since you're trying to address
older "v2" browsers.  So you really do need to look at the "User-Agent"
in the HTTP request -- but it's not an "XML capable browser" issue,
just a "requires broken HTML" issue.

Again, my bias would be to treat old browsers as the exception case,
and just serve up XHTML unless you recognize an "old" browser.  (Of
course, provide an "old browser" button in the XHTML page too.)  But
whether you treat "old" or "new" as the exception is your call.

For what it's worth, I just use the "transitional" XHTML DTD since
HTML browsers don't tend to handle enough of CSS to use "strict".
I've found that providing valid XHTML tends to make browsers like
Netscape 4.x handle CSS better ... and even then, there are some
valid constructs they won't quite be happy with!  :-)

Sorry I don't have a list of such browsers, but you should be able
to have your webserver tell you about the browsers your readers use.

- Dave



rev-bob@gotc.com wrote:
> 
> > Since your output choices are currently limited to HTML and XHTML, I'd
> > be sorely tempted to just default to XHTML, and give folk an option to
> > go to HTML output if that breaks.
> >
> > The reason is that most reasonably well crafted XHTML will be accepted by
> > both HTML and XML aware browsers, with the primary known exception being
> > very old browsers ("version 2") that you may not support anyway.
> 
> The trouble with that is, I kind of make a crusade out of accessibility.  Just about
> anybody can access my HTML, because I've taken care to include several legacy
> support tricks (such as a SCRIPT element inside a NOSCRIPT element, which is
> specifically designed to work around the fact that NN2 doesn't know what NOSCRIPT
> means) which are spec-illegal yet necessary for old-client support.
> 
> With the XHTML pages, I'm trying to get away from that.  Since old browsers don't
> understand XML, I can drop a lot of the antiquated hacks and make the XHTML code a
> bit cleaner.  Hence, the need for a client sniffer - send the older browsers to the HTML
> code which makes allowances for them, and shamelessly take advantage of the XML-
> compliant browsers' features.
> 
> > You only really need XML support in the client if you're trying to use
> > the XML/CSS (or eventually XML/XSLT) style rendering.  Since I couldn't
> > use IE5 support for that (no list or link support, or preformatted text),
> > and Mozilla's not prime-time yet, I'd not bother with that approach for
> > some time to come.
> 
> Look at it this way.  If I get the sniffer working, I can do things like morph FONT FACE
> tags into CSS styles for the XHTML version, thus ultimately bringing the XHTML
> version several steps closer to the ideal of divorcing content from presentation.  That's
> my goal; I'm not looking for XML support because I need it, but because excluding
> browsers without it will let me get closer to "pure code" in those pages.
> 
>  Rev. Robert L. Hood  | http://rev-bob.gotc.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From smuench at us.oracle.com  Wed Nov  3 19:30:06 1999
From: smuench at us.oracle.com (Steve Muench)
Date: Mon Jun  7 17:16:30 2004
Subject: Newbie - How to Load XML data into Oracle
In-Reply-To: <698DB793D712D31180B600902746422D84757E@exchange01.bnl.gov>
Message-ID: <NDBBLNLJDKJKCLEPFNNACEFACAAA.smuench@oracle.com>

See the "OracleXMLSave" class & utility
provided with the "Oracle XML SQL Utilities
for Java". Combined with transformations,
this provides the ability to easily get
XML data into the database on your terms.

http://technet.oracle.com/tech/xml

thanks.

______________________________________________
Steve Muench
Consulting Product Manager & XML Evangelist
Business Components for Java Development Team

| -----Original Message-----
| From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
| Gorden-Ozgul, Patricia E
| Sent: Wednesday, November 03, 1999 6:40 AM
| To: 'XML-DEV LIST'
| Subject: Newbie - How to Load XML data into Oracle
|
|
| I'm new to the world of SGML (not new) and XML (new) and document
| processing.  I am an Oracle developer/DBA.
|
| My understanding of the my part of the project is to load the XML
| data into
| an Oracle database (8.x on Solaris 2.6) from which we will be creating XML
| for a required data call.  The XML output will be 'passed'
| through multiple
| DTDs based upon which type of document is represented.
|
| I have never worked with variable length, multiple line tagged
| data before.
| Is anyone out there familiar with the method by which I could
| perform such a
| load?  It looks to me like Oracle's load utility, SQL*LOADER
| couldn't handle
| this.  To use it I'd need to convert the XML data to a delimited
| flat file.
|
| Does anyone out there have any suggestions or help for me?
| TIA
|
| * * * * *
| Pat Gorden-Ozgul
| Database Development
| Information Services Division Bldg 477
| Brookhaven National Laboratory
| Upton, New York   11967
| (516)344-5159     gorden@bnl.gov
|
| I take sole responsibility for any opinion expressed herein.
| * * * * *
|
|
|
| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
| Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
| CD-ROM/ISBN 981-02-3594-1
| To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
| unsubscribe xml-dev
| To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 19:45:17 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:30 2004
Subject: A Plea for Schemas
References: <3.0.32.19991101145442.00c09af0@pop.intergate.bc.ca> <381EB94E.76946432@praxis.cz>
Message-ID: <382090AE.C287EDBB@pacbell.net>

Matthew Gertner wrote:
> 
> 	...  many of the pieces of the
> puzzle have been in place only recently (or are still being worked on):
> 
> * The right mindset: until very recently generic markup has been seen as
> primarily useful for documents, where the utility of schemas is
> admittedly limited for anything but authoring applications. The idea of
> using XML as a software engineering tool to model data structures has
> now become very prevalent.

Or at least trendy.  There have been MANY (!) modeling infrastructures
intended to help certain classes of software engineers.  Watching those
tools' progress has led me to my current skeptical stance about other
attempts to deploy such modeling frameworks.  The low level tool used
to represent such models (XML in this example) doesn't matter much; it
is the higher level processes that create problems.


> * Communications infrastructure: Something like an automatic discovery
> mechanism for schemas would not be possible without widespread access to
> a common network infrastructure.

On the other hand, that widespread access can obviate the need
for such an "automatic discovery mechanism" just as easily, since
it enables other alternatives too.  It reduces all kinds of costs.

Near as I can tell, what you seem to be after with the "automatic
discovery" is primarily to make it easier to reuse a schema if that's
what a system designer wants to do.  But it can't make the designer
ignore common motivations like "NIH", "I can do it better", "that's
really not what we need", and the classic "we need a proprietary hook
to lock-in customers".

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lgeorge at gmx.net  Wed Nov  3 20:33:16 1999
From: lgeorge at gmx.net (Lars George)
Date: Mon Jun  7 17:16:31 2004
Subject: XSL
In-Reply-To: <NBBBLIPEHIMMNAPFNOLCCEKBEBAA.antons@epos.co.za>
Message-ID: <001001bf263a$d7c82500$0900000a@larsgeorge01>

Hi Anton,

I do the same thing but on the server-side. Have a look at IBM's Alphaworks
site into the source of the XMLEnabler. This is a servlet that does the same
thing. It even gives you a chance to decide which XSL you use for which user
agent (browser). Therefore you can transform your data on the server and
serve it to all available browsers out there just by providing different XSL
stylesheets. I find that rather amazing, and it is simple too!

HTH,

Lars George
Woodgate Research Pty Ltd
Brisbane, Australia

> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Anton Schoultz - ePOS
> Sent: Wednesday, 3 November 1999 21:41
> To: XML-DEV LIST
> Subject: XSL
>
>
> Hi all,
> Yet another idiot question..
> I have found lots of info on XML, and lots on XSL, but very little on
> combining them!
>
> Hypothetical case; let's say that I have a servlet (eg Java) runing which
> accepts an HTTP POST/GET to query a product catalogue. The
> servlet queries a
> database and then generates an XML document such as this..
>
>
> <?xml version="1.0"?>
> <!DOCTYPE ProdList SYSTEM "http://www.acme.com/dtd/ProdList.dtd">
> <ProdList>
>  <hdr date="19991201">
>   <title>Catalogue as of 1st December</title>
>  </hdr>
>  <prod code="101" short="keyboard" price="50.00">Qwerky keyboard</prod>
>  <prod code="MS1" short="Mouse" price="5.00">Mickey Mouse</prod>
>  <prod code="CRT2" short="Monitor" price="100.00">Monitor Lizard</prod>
> </ProdList>
>
>
> Let's say we have a DTD available on the web server
> "www.acme.com/dtd/ProdList.dtd"
> which looks like this..
>
> <!ELEMENT ProdList ( hdr, prod* ) >
>   <!-- header specifies effective date -->
>   <!ELEMENT hdr ( title? ) >
>   <!ATTLIST hdr
>     date CDATA #IMPLIED
>   >
>   <!ELEMENT title (#PCDATA)* >
>   <!-- each product has a code, short-descripiton and a price. -->
>   <!-- the data holds full description -->
>   <!ELEMENT prod (#PCDATA)* >
>   <!ATTLIST prod
>     code  CDATA #REQUIRED
>     short CDATA #IMPLIED
>     price CDATA #IMPLIED
>   >
> >
>
> Let's say that a style sheet is also available on www.acme... to ouput the
> catalogue as an HTML table, looks like this ... (which probably
> has lots of
> errors!)
>
> <?xml version="1.0"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org.TR/WD-xsl">
>   <xsl:template match="/">
>     <HTML>
>       <HEAD>
>         <TITLE>
>          <xsl:for-each select="hdr">
>            <xsl:value-of select="."/>
>          </xsl:for-each>
>         </TITLE>
>       </HEAD>
>       <BODY BGCOLOR="#808080">
>         <H1>Product List</H1>
>         <TABLE BORDER="1" WIDTH="400">
>           <TR>
>             <TH>Stock Code</TH>
>             <TH>Short Description</TH>
>             <TH>Long Description</TH>
>             <TH>Unit Price</TH>
>           </TR>
>           <xsl:for-each select="ProdList/prod">
>             <TR>
>               <TD> <xsl:value-of select="@code"/>  </TD>
>               <TD> <xsl:value-of select="@short"/> </TD>
>               <TD> <xsl:value-of select="."/>      </TD>
>               <TD> <xsl:value-of select="@price"/> </TD>
>             </TR>
>           </xsl:for-each>
>         </TABLE>
>       </BODY>
>     </HTML>
>   </xsl:template>
> </xsl:stylesheet>
>
>
>
> How should the servlet change it's ouput (text/xml?) so that the
> browser (eg
> IE5) will pick-up the XSL and format the xml output into the desired HTML
> table ?
> What changes are required to the above files ?
>
> Regards
>
> Anton Schoultz
> e-mail: mailto:antons@ePOS.co.za
> Office: +27 11 807-9400 Ext. 205
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From andre.camenzind at alcatel.ch  Wed Nov  3 20:59:38 1999
From: andre.camenzind at alcatel.ch (=?iso-8859-1?Q?Andr=E9?= Camenzind)
Date: Mon Jun  7 17:16:31 2004
Subject: XSL
References: <001001bf263a$d7c82500$0900000a@larsgeorge01>
Message-ID: <3820A21B.19057F17@alcatel.ch>



Lars George wrote:

> Hi Anton,
>
> I do the same thing but on the server-side. Have a look at IBM's Alphaworks
> site into the source of the XMLEnabler. This is a servlet that does the same
> thing. It even gives you a chance to decide which XSL you use for which user
> agent (browser). Therefore you can transform your data on the server and
> serve it to all available browsers out there just by providing different XSL
> stylesheets. I find that rather amazing, and it is simple too!

Hello

Thanks for the tip Lars.
The XMLEnabler seems to be a really nice tool, but it looks like that you have to use the
Lotus XSL Processor. Is it possible to use another XSL Processor? Has anyone tried to use
another XSL Processor?

Regards

Andre Camenzind
-------------- next part --------------
A non-text attachment was scrubbed...
Name: andre.camenzind.vcf
Type: text/x-vcard
Size: 291 bytes
Desc: Card for André Camenzind
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991103/500e9dac/andre.camenzind.vcf
From wunder at infoseek.com  Wed Nov  3 21:31:20 1999
From: wunder at infoseek.com (Walter Underwood)
Date: Mon Jun  7 17:16:31 2004
Subject: XSL
In-Reply-To: <001001bf263a$d7c82500$0900000a@larsgeorge01>
References: <NBBBLIPEHIMMNAPFNOLCCEKBEBAA.antons@epos.co.za>
Message-ID: <3.0.5.32.19991103132814.00be2100@corp.infoseek.com>

At 06:34 AM 11/4/99 +1000, Lars George wrote:
>
> ... It even gives you a chance to decide which XSL you use for which user
>agent (browser). Therefore you can transform your data on the server and
>serve it to all available browsers out there just by providing different XSL
>stylesheets.

Be sure to do something sensible for unrecognized user agents.
Our spider got an error message for every single page at one
site, because the site didn't know what to do for the user-agent
(browser) called "Ultraseek".

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov  3 21:37:35 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun  7 17:16:31 2004
Subject: Fw: XHTML 1.0 returned to HTML WG
Message-ID: <002b01bf2643$1a739530$2a7b0a0a@ridge.w3.org>

FYI - tim

-----Original Message-----
From: Tim Berners-Lee <timbl@w3.org>
To: w3c-ac-members@w3.org <w3c-ac-members@w3.org>
Date: Wednesday, November 03, 1999 11:22 AM
Subject: W3C: XHTML 1.0 returned to HTML WG


>
>Dear Advisory Committee Member,
>
> XHTML 1.0 is hereby sent back to the HTML working group for further work.
>
>On 24th August 1999, we asked for review of the XHTML 1.0 Proposed
>Recommendation. The review period lasted until September 22nd. It
>was encouraging to see so many member organizations planning on
>delivering products supporting XHTML.
>
>There was, however, a significant lack of consensus around a number of
>points, based on the feedback received during the review. The HTML
>working group is being asked to address the issues raised and to
>present a revised specification for further member review as soon
>as possible.
>
>In summary, W3C Members wanted the HTML working group to revise
>the XHTML 1.0 specification to utilize a single namespace.
>There are a number of separate questions involved in this,
>such as whether a namespace identifier should be changed
>(a) between versions of the same specification and (b) between
>different strict, transitional and frameset document types of the
>original HTML 4 spec on which xHTML is based.
>
>A few respondents were also concerned about the use of the text/xml
>media type for delivering xHTML, considering this to be "premature".
>If a document conforming to XML 1.0 and XML Namespaces is not to be
>considered "text/xml", this raises an important issue as to what is.
>
>Whatever decision is made, XHTML as a specification must of
>course define some conformance phrase (what it is that it is defining)
>and the constraints on and meaning of a conforming document.
>
>We will be sending out a separate message on the HTML 4.01
>specification, which was reviewed at the same time as XHTML 1.0.
>
>Tim Berners-Lee
>Director W3C
>
>
>
>
>


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



From lgeorge at gmx.net  Wed Nov  3 22:04:26 1999
From: lgeorge at gmx.net (Lars George)
Date: Mon Jun  7 17:16:31 2004
Subject: XSL
In-Reply-To: <3820A21B.19057F17@alcatel.ch>
Message-ID: <001301bf2647$70215770$0900000a@larsgeorge01>

Hi Andre,

I have done the same sort of servlet (only a basic version) without the
knowledge of IBM XMLEnabler. Basically even that servlet is just a template
and gives you a good start what has to be done. The XSL processor and XML
parser part is replaceable by any of them. I use the Oracle ones right now,
as they come nicely wrapped up in one package. Works just fine although this
is still work in progress (i.e. XSL and my servlet). Another good source og
information is the Cocoon project on the Apache website
(http://java.apache.org). They do the same thing but have built a framework
that allows for easy replacement of XSL/XML packages. They already support
the major ones, but as a framework it can be easily extend to support new
ones, too.

The gist is to take the user agent info and transform the XML to whatever is
needed. Bear in mind the note Walter posted just before. Always provide for
a fallback if you can't detect the user agent.

HTH,

Lars George
Woodgate Research Pty Ltd
Brisbane, Australia

> -----Original Message-----
> From: Andr? Camenzind [mailto:andre.camenzind@alcatel.ch]
> Sent: Thursday, 4 November 1999 6:59
> To: Lars George
> Cc: Anton Schoultz - ePOS; XML-DEV LIST
> Subject: Re: XSL
>
>
>
>
> Lars George wrote:
>
> > Hi Anton,
> >
> > I do the same thing but on the server-side. Have a look at
> IBM's Alphaworks
> > site into the source of the XMLEnabler. This is a servlet that
> does the same
> > thing. It even gives you a chance to decide which XSL you use
> for which user
> > agent (browser). Therefore you can transform your data on the server and
> > serve it to all available browsers out there just by providing
> different XSL
> > stylesheets. I find that rather amazing, and it is simple too!
>
> Hello
>
> Thanks for the tip Lars.
> The XMLEnabler seems to be a really nice tool, but it looks like
> that you have to use the
> Lotus XSL Processor. Is it possible to use another XSL Processor?
> Has anyone tried to use
> another XSL Processor?
>
> Regards
>
> Andre Camenzind
>


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



From ht at cogsci.ed.ac.uk  Wed Nov  3 22:29:17 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:16:31 2004
Subject: Undeclared namespace
In-Reply-To: "Anand Raman"'s message of "Sat, 30 Oct 1999 16:31:13 +0530"
References: <3819335F.F773CE42@wipsys.soft.net> <3819937E.9F1D4610@goon.stg.brown.edu> <381ACFF8.3C574509@wipsys.soft.net>
Message-ID: <f5bg0yn6wmj.fsf@cogsci.ed.ac.uk>

You have to put a FIXED xmlns:foo declaration on EVERY element in your 
DTD which appears in your input document with an explicit NS prefix.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From jelks at jelks.nu  Wed Nov  3 23:13:20 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:31 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <002b01bf2643$1a739530$2a7b0a0a@ridge.w3.org>
Message-ID: <NBBBICMNIPCICMKJECCBCEABDBAA.jelks@jelks.nu>

Tim Berners-Lee wrote:

> > XHTML 1.0 is hereby sent back to the HTML working group for further work.

...

> >In summary, W3C Members wanted the HTML working group to revise
> >the XHTML 1.0 specification to utilize a single namespace.
> >There are a number of separate questions involved in this,
> >such as whether a namespace identifier should be changed
> >(a) between versions of the same specification and (b) between
> >different strict, transitional and frameset document types of the
> >original HTML 4 spec on which xHTML is based.

Would it not save everyone a lot of anguish if XHTML 1.0 were just HTML 4.01
recast as XML 1.0, in other words without mentioning namespaces *at all*, and
saving the namespace stuff for future versions (if it's proven to be viable)?

/Jelks


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



From Curt.Arnold at hyprotech.com  Wed Nov  3 23:32:09 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:16:31 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <61DAD58E8F4ED211AC8400A0C9B4687341546D@THOR>

Tim Berners-Lee wrote:

>>Subject: Fw: XHTML 1.0 returned to HTML WG
>>In summary, W3C Members wanted the HTML working group to revise
>>the XHTML 1.0 specification to utilize a single namespace.

I think the motivation for the three namespaces and the fact that there
hasn't been a clean, popular resolution to the underlying problem is a
result that there is not a clean way to distinguish between what a
DTD/schema is capable of representing and what an application is capable of
processing.  I know namespaces aren't equivalent to a DTD or Schema, but I
think that in this case they are felt to be the moral equivalent of a DTD.
I've tried to expand a little on this in comments on the Schema drafts, but
I think it is an important distinction.

For example, a well defined address schema should be able to handle non-US
addresses.  A particular mailing label printer might only support US
addresses.  It would be nice if the XML infrastructure would allow a routing
program to recognize that a particular address did not conform to the
capabilities of the US mailing label printer and route it to an non-US
capable printer.  One option would be to cripple the schema, but this
inhibits those applications that are non-US capable.

Basically, what this would require is the document to be able to declare
what DTD/Schema that it governs it (either through a <!DOCTYPE or through
whatever mechanism the Schema group decides to associate a schema with a
document) and optionally what usage profiles to which the document conforms.


To me, declaration of usage profiles fit the definition of a processing
instruction (I don't know what the implications of using a PI with the
existing HTML browsers is however).  It is a hint to the processor that the
XML document that follows only uses a subset of the available constructs.
The processor would eventually determine if the XHTML uses frames when it
encountered the <FRAME> element, the PI would just let it know before hand.

A question would be should we try to develop a standard way of designating
document profiles or provide an XHTML specific manner.

If we were just addressing, XHTML we could do something line

<?xhtml frameset="false" strict="true"?>

If we were trying to be more generic, could we do something like

<?xml profile="uri uri uri"?>

To list the profiles that the document adheres to.  For XHTML the uri's
would be urn's that identify the frameset, strict and transitional profiles.
For other applications, these could be url's that point to DTD's or a schema
profile.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  3 23:38:08 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:16:31 2004
Subject: XHTML 1.0 returned to HTML WG
References: <NBBBICMNIPCICMKJECCBCEABDBAA.jelks@jelks.nu>
Message-ID: <049b01bf2654$4b7d1460$1918ccce@murphy>

>>Would it not save everyone a lot of anguish if XHTML 1.0 were just HTML
4.01
recast as XML 1.0, in other words without mentioning namespaces *at all*,
and
saving the namespace stuff for future versions (if it's proven to be
viable)?

Yes yes yes!!

That would get XML into the minds of HTML coders and would start a process
for other applications of XML to take off.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 00:08:13 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:31 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <NBBBICMNIPCICMKJECCBCEABDBAA.jelks@jelks.nu>
Message-ID: <000601bf2658$c6072dc0$099918d1@docuverse1>

>Would it not save everyone a lot of anguish if XHTML 1.0 were 
>just HTML 4.01
>recast as XML 1.0, in other words without mentioning 
>namespaces *at all*, and
>saving the namespace stuff for future versions (if it's proven 
>to be viable)?

I don't see much difference between zero and one (one?:) namespace
and since there is definite need for a namespace (i.e. XSL) to
distinguish (X)HTML tags from others, I prefer one over zero.

I must say, I was surprised by the decision and have now a more
healthy respect for the W3C process although I suspect XML-DEV has
now become an informal part of the process.  At least all the
stress we must go through to exert that reactive influence is
high enough to prevent abuse <g>.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Curt.Arnold at hyprotech.com  Thu Nov  4 00:28:38 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:16:31 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <61DAD58E8F4ED211AC8400A0C9B46873415470@THOR>

Dave Winer wrote:
>>
>>Yes yes yes!!
>>
>>That would get XML into the minds of HTML coders and would start a process
>>for other applications of XML to take off.
>>
>>Dave

After ranting on application profiles, etc.  I wanted to clarify that it
doesn't seem to be necessary to get an answer to application profiles for
XHTML to be useful.  Application profiles would be a useful thing to have
resolved for other XML applications, but doesn't seem necessary for XHTML
1.0.  The three namespaces thing seemed to be adding a feature to XHTML 1.0
that HTML 4.01 did not have.  As a new feature, it should have probably been
reserved for XHTML 1.1 or whatever.  

Namespace free XHTML would be fine with me.  However, if XHTML must deal
with application profiles, I'd like it to establish a pattern that other xml
applications could follow.  However, I think that is better left to the
schema group (and maybe to XML Schema 1.1)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 01:10:53 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <3.0.32.19991103170850.00cfeb50@pop.intergate.ca>

At 06:12 PM 11/3/99 -0500, Jelks Cabaniss wrote:
>Would it not save everyone a lot of anguish if XHTML 1.0 were just HTML 4.01
>recast as XML 1.0,

That's what it is.

> in other words without mentioning namespaces *at all*, and
>saving the namespace stuff for future versions (if it's proven to be viable)?

Lots of people have good solid practical uses for namespaces.  Anyone who
thinks that HTML can go forward standing alone in glorious isolation and
never being mixed with another tag vocabulary Just Doesn't Get It.

So XHTML needs a namespace, and the HTML WG is the correct group to assign 
it.  Whether they want to do it as part of the XHTML 1.0 spec or simply as
a 3-line W3C recommendation published separately makes little 
difference. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Thu Nov  4 01:32:01 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <000601bf2658$c6072dc0$099918d1@docuverse1>
Message-ID: <NBBBICMNIPCICMKJECCBCEAGDBAA.jelks@jelks.nu>

Don Park wrote:

> I don't see much difference between zero and one (one?:) namespace
> and since there is definite need for a namespace (i.e. XSL) to
> distinguish (X)HTML tags from others, I prefer one over zero.

XSL currently handles HTML, text, and XML 1.0 output without need for any
specified namespace in either the input or the output.

/Jelks


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 01:47:50 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <3.0.32.19991103170850.00cfeb50@pop.intergate.ca>
Message-ID: <199911040134.UAA26222@hesketh.net>

At 05:08 PM 11/3/99 -0800, Tim Bray wrote:
>So XHTML needs a namespace, and the HTML WG is the correct group to assign 
>it.  Whether they want to do it as part of the XHTML 1.0 spec or simply as
>a 3-line W3C recommendation published separately makes little 
>difference. -Tim

Except that the second route probably would have gotten XHTML 1.0 through
without these hitches.  Technically, you're quite right.  Politically, I
think this could have been easier.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 01:50:53 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:32 2004
Subject: A Plea for Schemas
References: <005801bf25bb$f5af9460$1cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <3820CF13.4EAD@hiwaay.net>

Rick Jelliffe wrote:
>
> Tim is of course correct that a schema is only part of the whole
> picture, but a schema language can be judged on how readily it allows
> useful systems and tools to be built.  

Ok.  Another way to look at it is to look at the frequency of 
change in the information and determine if a schema is an 
where in the process the schema is an effective tool.  There 
are a lot of applications whose market loosely hangs 
in the "authoring" category.  Is anyone applying schemas to dimensions 
for multi-dimensional database designs, yeVenerableHypercubes 
for online analytical processing?

> That being so, it may be a strong
> schema system is one which has some 'use' information as well as the
> "pure" schemas: documentation, forms building, validation, style, etc.:
> where the type information from the schema can directly be used for some
> purpose.
> 
> DTDs provide simple stucture models but also have infoset contributions
> with #FIXED attributes and default attribute values (i.e., a simple
> transformation of the instance). This makes them 'impure' as a schema
> language, but undoubtedly more useful.

Schemas that gracefully handle time volatility issues will be useful. 
However for that to work, the schema has to be dynamic, and I rather 
thought that was the attractiveness of XML schemas.  I can instrument 
processes and use the events to modify a schema via the DOM, thus 
closing the loop.  Better than hardwiring templates, I would think.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 02:25:11 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: "Simon St.Laurent"'s message of "Wed, 03 Nov 1999 20:34:30 -0500"
References: <199911040134.UAA26222@hesketh.net>
Message-ID: <m31za7atc1.fsf@localhost.localdomain>

"Simon St.Laurent" <simonstl@simonstl.com> writes:

> >So XHTML needs a namespace, and the HTML WG is the correct group to assign 
> >it.  Whether they want to do it as part of the XHTML 1.0 spec or simply as
> >a 3-line W3C recommendation published separately makes little 
> >difference. -Tim
> 
> Except that the second route probably would have gotten XHTML 1.0 through
> without these hitches.  Technically, you're quite right.  Politically, I
> think this could have been easier.

I have customers who would invest a lot of time and energy in XHTML
right now, and who would integrate XHTML into other major industry
specs that will be too far along to mess with in another few months,
if the HTML WG would only publish a one-sentence NOTE that said

  The XML Namespace for HTML is http://www.w3.org/1999/11/HTML/ and
  all names are lower case.

(or whatever suits).  Really -- just give us a Namespace, and we'll
do stuff you barely dare to dream about.  That way, they can work on
XHTML itself, modules, and all that at leisure.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Thu Nov  4 02:59:28 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <3.0.32.19991103170850.00cfeb50@pop.intergate.ca>
Message-ID: <NBBBICMNIPCICMKJECCBKEAHDBAA.jelks@jelks.nu>

Tim Bray wrote:

> Lots of people have good solid practical uses for namespaces.  Anyone who
> thinks that HTML can go forward standing alone in glorious isolation and
> never being mixed with another tag vocabulary Just Doesn't Get It.

The How, not the What, is what's contentious.  Look at this list for the last
several months.  Do we need that to hold back xHTML 1.0 for another three months
or more?

/Jelks



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 02:59:21 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <NBBBICMNIPCICMKJECCBCEAGDBAA.jelks@jelks.nu>
Message-ID: <000001bf2670$af0caf60$099918d1@docuverse1>

>XSL currently handles HTML, text, and XML 1.0 output without 
>need for any
>specified namespace in either the input or the output.

You are right but if you want to use XSL to generate composite
documents which requires using multiple namespaces, HTML tags
will have to be treated as a special case if it lacked a
namespace.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 02:59:30 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <m31za7atc1.fsf@localhost.localdomain>
Message-ID: <000101bf2670$c67df780$099918d1@docuverse1>

>  The XML Namespace for HTML is http://www.w3.org/1999/11/HTML/ and
>  all names are lower case.

I am all for this idea.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From DKGunter at lbl.gov  Thu Nov  4 03:01:49 1999
From: DKGunter at lbl.gov (Dan Gunter)
Date: Mon Jun  7 17:16:32 2004
Subject: dynamic XML?
References: <199911040134.UAA26222@hesketh.net> <m31za7atc1.fsf@localhost.localdomain>
Message-ID: <3820F64E.EB5CDCC1@lbl.gov>

Hi,

I am working with some people who want to publish performance monitoring
information in a standard exchange format. The details of the common
vocabulary are still being discussed, but even at this early stage there
are some technical questions about XML's use for such a task.

One question is: assuming that the "things" being monitored, as well as
the "characteristics" of the things being recorded, can change over
time, is there a good way to dynamically add (even subtract) bits and
pieces of the schema during the lifetime of the connection? I was
thinking of something along the lines of a special couple of tags that
tell the client to add/remove "things" or "characteristics" from its
expected monitored events. Perhaps some of you have seen variations on
this problem before?

As a side note, XSchema looks more attractive than DTD's for this
application (strict typing, among other things, would be nice). 

Thanks,

-- 
[............. Dan Gunter - LBNL ....................]
[One Cyclotron Road, MS:50B-2239, Berkeley, CA 94720 ]
[(510)495-2504 / DKGunter@lbl.gov                    ]

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



From tania at bic.nus.edu.sg  Thu Nov  4 03:03:50 1999
From: tania at bic.nus.edu.sg (TaNiA)
Date: Mon Jun  7 17:16:32 2004
Subject: can anyone help?
Message-ID: <01da01bf2671$0c46f500$52138489@bic.nus.edu.sg>

Hi XML gurus,

Can anyone give me some pointers in building an XML TOC like Microsoft has?
http://msdn.microsoft.com/workshop/xml/toc.htm

Thanks in advance,
tania





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 03:39:41 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
References: <199911040134.UAA26222@hesketh.net> <m31za7atc1.fsf@localhost.localdomain>
Message-ID: <3820FE0E.4C68@hiwaay.net>

David Megginson wrote:
> 
> (or whatever suits).  Really -- just give us a Namespace, and we'll
> do stuff you barely dare to dream about.  That way, they can work on
> XHTML itself, modules, and all that at leisure.

Well said.  But the spec is back for work, so, selah.

Geekery... I've been reading Neil Maden's papers on OLAP 
and multi-dimensional databases for fun.  

Why isn't more of the list focus integrating XML for the 
client into the analytical systems so the closed loop from the 
document dbs to the decision systems is cohesive, fast, and 
easier to build than hypercubes.  Hypercubes are morph 
based names in a slice and dice API. Separate facts/measure 
tables (numerical) from dimensions.   Isn't a star-based 
named schema and relating XML schemas in the namespace 
of a metaName set the same thing?

I don't know... fun to consider.  Tumblers in the namespace..

The problem of applying schemas is applying them without 
the idea of dynamically modifying them so they will pivot, 
drill, mine, what have you.  The document structure, 
if apriori, the schema names, is the range of the 
querying space.  To aggregate, names must aggregate. 
If that is definitional, authoritative, schemas must 
be dynamic.  Otherwise, they are (neil maden) "time volatile".

Isn't a schema the set of names available to 
query in the space, apriori?  To me, that is 
the main value.  The dropdown list. 

My task tonight is to map two 
languages, both nodal and field, element and attribute. 
To do this, I have to abstract out the node names 
from the namespace of both languages and determine 
the state of the map (language name pairs or outermost 
nodes).  Do I need a higher level set of names?

yeah... the names of the document parts.  legally, 
that is the last level of name binding.  the document.

The dropdown list.  Authoring is the user interface. 
That namespace is the legal definition.

The importance of document systems namespaces
is the kind of information traditionally kept in them.  
The habit of the culture is to put the information for 
the humans in them, and that is precisely the information 
one needs to create dimensional data because it describes 
how the humans think they use it.  In legal systems based 
on records of authority, it is the text references that 
bear the responsibility that node names carry in namespaces: 
referent stabilization.

A DTD is a hedge on entropy.  Even if the rule is 
volatile, if applied, the value of the referent 
becomes persistent.  Persistence is enough to 
control the rate of change of the definitions 
and their affects on the objects they govern.

A good analytical engine should let you query that 
by simple means.  Navigate topical 
schemas or use the morphology of the 
namespace to store the dimensions.  Manipulate it, 
and let the indexing magic work on the facts.  Intersections 
are facts.  OLAP. m-space.

Something else.  X3D ends up putting in externProtos and 
Protos so the language is at least, extensible by declarative 
aggregation.  I suggest the markup community adopt similar 
means.  We must have it for the 3D graphics and it is 
in the abstract set, so it has to be provided.  If the idea 
is useful and generalizable, go for it.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Thu Nov  4 04:47:21 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <199911032346406.SM00242@Unknown.>

> >>Would it not save everyone a lot of anguish if XHTML 1.0 were just HTML
> >> 4.01 recast as XML 1.0, in other words without mentioning namespaces *at all*,
> >> and saving the namespace stuff for future versions (if it's proven to be viable)?
> 
> Yes yes yes!!
> 
> That would get XML into the minds of HTML coders and would start a process
> for other applications of XML to take off.

Okay, maybe I'm a little brighter than the HTML coders you're thinking of, but I 
spawned an XHTML version of my site with fairly little trouble.  In fact, the hardest part 
was (a) getting a list of empty elements (I'd somehow overlooked INPUT and META), 
(b) finding those elements in my files so I could convert <tag> to <tag /> as appropriate, 
(c) converting all my links so they'll switch from page.html to page.xml as necessary, and 
(d) tracking down all those pesky uppercase tags and (worst of all) unquoted attribute 
values.  A good multi-file search&replace utility took care of step B, I'd anticipated most 
of step C months ago and already made the adjustments, and testing pages with IE5 took 
care of most of step D.  Yeah, I may have some pages out there with an uppercase 
element or two - but the vast majority of the conversion is done, and it validates cleanly.

With all those concerns to worry about...well, frankly, adding a namespace attribute to 
my <html> tag was nothing.  The defined namespaces precisely parallel the existing 
HTML 4 DTDs, which I was already using; adding them in was cake.  I didn't look over 
the XHTML spec and panic because I didn't know what a namespace was or what that 
attribute meant; it just wasn't that big a deal.  HTML didn't require it; XHTML did - 
fine.  Right along with <br /> instead of <br>.  It's a syntax adjustment; I adjusted.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


*---------------------------------------------------------*
       E-Mail Delivery By VEI Internet Mail Services
   http://www.veiinternet.com - $14.95 Unlimited Internet

       Visit The New VEI Stores Open For Christmas:
       VEI DVD Store - http://vei.vstoredvds.com/
       VEI Book Store - http://veibooks.vstorebooks.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Thu Nov  4 05:37:31 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:32 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <199911040036117.SM00242@Unknown.>

Curt Arnold sez:

> After ranting on application profiles, etc.  I wanted to clarify that it
> doesn't seem to be necessary to get an answer to application profiles for
> XHTML to be useful.  Application profiles would be a useful thing to have
> resolved for other XML applications, but doesn't seem necessary for XHTML
> 1.0.  The three namespaces thing seemed to be adding a feature to XHTML 1.0
> that HTML 4.01 did not have.  As a new feature, it should have probably been
> reserved for XHTML 1.1 or whatever.  

Actually, I found the namespace feature to be handy and quite logical, paralleling the 
triple DTD for HTML 4.0.  But then, I just tinkered a bit with my processor and didn't 
have any problems making it work.  (I use one macro which generates the !DOCTYPE 
statement, as I don't like to have to remember that whole string.  When I added the 
XHTML processing path, I just reworked the macro so that it would handle the 
!DOCTYPE statement and the <html> tag - and, on the XHTML side, it also adds the 
namespace stuff and the <?xml?> tag.)

As for reserving the feature for XHTML 1.1...why?  XHTML 1.0 is a significant jump 
that will require almost every webmaster on the planet to do some fixing...given that 
scope, how significant is the effort expended to change the opening <html> tag?!?

> Namespace free XHTML would be fine with me.

Depends on what you mean by that; I see the dangerous potential there of descending 
into the same morass we currently have with HTML, where we theoretically go by the 
DTD, but in actuality, it's anybody's guess what browserisms a random user agent will 
support.  Witness the spotty support CSS1 and CSS2 have, not to mention HTML4 
itself.

As a content provider, I don't mind the namespace attribute one bit.  It's just one more 
thing to remember when coding, and I have a nice tool which remembers that for me - in 
short, I literally dropped the code in and forgot about it.  From the programming side, I 
really don't see a whole lot of difference; if the UAs we have for HTML blithely ignore 
specified DTDs when given as !DOCTYPE statements, why should we expect that the 
UAs we will have for XML will do any better?



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


*---------------------------------------------------------*
       E-Mail Delivery By VEI Internet Mail Services
   http://www.veiinternet.com - $14.95 Unlimited Internet

       Visit The New VEI Stores Open For Christmas:
       VEI DVD Store - http://vei.vstoredvds.com/
       VEI Book Store - http://veibooks.vstorebooks.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From AlanM at SYNECTICS.Soft.net  Thu Nov  4 05:50:24 1999
From: AlanM at SYNECTICS.Soft.net (Alan Menezes)
Date: Mon Jun  7 17:16:32 2004
Subject: EDIFACT
Message-ID: <1F4436D26763D2119B8800A0C9DE689797E228@MAIL>

Hi all.
What are EDIFACT tags? please specify ansy site.
Can EDIFACT tags be converted to self describing tags. 
Please give me details.
Thanks
Alan

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



From liamquin at interlog.com  Thu Nov  4 06:25:48 1999
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:16:33 2004
Subject: public identifiers [Re: Referencing multiple DTD in an XML document]
In-Reply-To: <3820142B.B9C1BF27@mecomnet.de>
Message-ID: <Pine.BSI.3.96r.991104012329.13636H-100000@shell1.interlog.com>

On Wed, 3 Nov 1999, james anderson wrote:
> David Brownell wrote:
[...]
> > I'd encourage you to use PUBLIC identifiers as well, so that
> > local cached copies of those declarations can easily be used.
> Could someone expound further on this statement?

I would *discourage* you from using PUBLIC identifiers.
Any system that bases caches on PUBLIC rather then SYSTEM identifiers
for XML is broken.

The PUBILC keyword is there for backwards compatibility with SGML;
its meaning in XML is not formally defined, and it's usually ignored.
Therefore, if you want interoperability, simply forget it's there.

[...]

> I've yet to see a conclusive discussion of whether
> dtd's (or for that matter schema) in the namespace age are stable. That is,
> whether the same system uri will always identify an identical dtd/schema.
They are not and it won't.

<!NOTATION sh SYSTEM "/bin/sh -c">
<!ENITY systemdate SYSTEM "/bin/date" NDATA sh>
now systemdate returns a different value every tiem you use it (maybe
evenwithin the same document, depending on the processor).

This use of NOTATION is implied by the XML spec and by the SGML handbook,
but since a docuemnt you recieve could just as easily use "format" or "rm",
it's not a good idea, by the way.

> For example, would a processor be conforming if it were to, upon not finding a
> resource "under" a public identifier, retrieve and expand the resource located
> through the system identifier and cache the expanded (or even decoded result)
> "under" the public identifier?
You can do whatever you like with a public identifier -- it's undefined.
No amount of wishful thinking will make it otherwise, for those who
want to use it :-) sorry.

Lee

-- 
Liam Quin, Barefoot Computing, Toronto;  The barefoot agitator
l i a m q u i n     at    i n t e r l o g    dot   c o m
Ankh on irc.sorcery.net, ankle5/Ankle{MD} on DALnet


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



From antons at epos.co.za  Thu Nov  4 07:14:22 1999
From: antons at epos.co.za (Anton Schoultz - ePOS)
Date: Mon Jun  7 17:16:33 2004
Subject: EDIFACT
Message-ID: <NBBBLIPEHIMMNAPFNOLCEEKKEBAA.antons@epos.co.za>

>Hi all.
>What are EDIFACT tags? please specify ansy site.
>Can EDIFACT tags be converted to self describing tags.
>Please give me details.
>Thanks
>Alan

Hi Alan,

EDIFACT (actually UN/EDIFACT see later) is an EDI standard, which conveys
information in pre-determined 'segments'. The segments each have a segment
'tag' (not to be confused with xml-tags!) which acts as a record ID.

These segments are NOT self defining, a big part of getting EDIFACT to work
is the 'dictionary' of segments.

You could think of UN/EDIFACT as being a *slightly* smarter form of a CSV
file, with delimited fields and sub-fields.

You could convert UN/EDIFACT to xml style tags and DTD's - search for 'XML
EDI'
or try http://www.geocities.com/WallStreet/Floor/5815/guide.htm

Hope this sheds some light...
Anton



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



From dag at orion.no  Thu Nov  4 07:14:00 1999
From: dag at orion.no (Dag Sunde)
Date: Mon Jun  7 17:16:33 2004
Subject: EDIFACT
References: <1F4436D26763D2119B8800A0C9DE689797E228@MAIL>
Message-ID: <000f01bf2693$a880e210$43145c3e@orion.no>

EDIFACT is an acronym for:
"Electronic Data Interchange For Administration , Commerce and Transport"

You should do a search for UN/EDIFACT, and take a look at:
http://www.unece.org/trade/untdid/d96a/cont_t.htm

HTH...

Dag Sunde.


----- Original Message -----
From: Alan Menezes <AlanM@SYNECTICS.Soft.net>
To: <xml-dev@ic.ac.uk>
Sent: Thursday, November 04, 1999 6:47 AM
Subject: EDIFACT


> Hi all.
> What are EDIFACT tags? please specify ansy site.
> Can EDIFACT tags be converted to self describing tags.
> Please give me details.
> Thanks
> Alan
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 07:56:31 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:33 2004
Subject: XHTML 1.0 returned to HTML WG
References: <"199911040036117.SM00242"@Unknown>
Message-ID: <38213911.7A0CD90A@pacbell.net>

WARNING:  I may risk re-igniting the N-namespaces war by responding ...

rev-bob@gotc.com wrote:
> 
> Curt Arnold sez:
> 
> > Namespace free XHTML would be fine with me.

Although I certainly suggested that at one point, I think _one_ is the
preferable outcome, and the motivation for _zero_ namespaces would only
have been to get XHTML out quicker than it appears can now happen.

 
> Depends on what you mean by that; I see the dangerous potential there
> of descending into the same morass we currently have with HTML, where
> we theoretically go by the DTD,

I never thought that HTML <!DOCTYPE ...> declarations were ever
usable for any purpose other than content providers to validate, in
order to work on more browsers.  How could they be?  I think that
HotJava once tried to validate -- and gave up quickly because so
many sites _only_ produce illegal HTML.


>	 but in actuality, it's anybody's guess what browserisms a random
> user agent will support.  Witness the spotty support CSS1 and CSS2 have,
> not to mention HTML4 itself.

Namespaces are for distinguishing an XHTML "table" from furniture, not
for nuancing IE4/Mac table browserisms (bugs) from NN4.61/Linux ones.

Nobody wants to see one namespace per "browserism", with a W3C precedent
in that space ... start with three "browserisms", and there will be
hundreds of different XHTML namespaces in no time at all.  Nobody will
even bother to look at the namespaces if that's how it goes.


> 	   why
> should we expect that the UAs we will have for XML will do any better?

Better in what respect -- being less buggy?  Two things come to mind:

  -  One is that so many developers understand the damage that comes from
     HTML standards being so thoroughly ignored ... which wasn't widely
     understood as the damage was being created.  XML has "draconian"
     error handling (no display if it's not well formed!), which is a
     big step forward (though it only goes so far).

     This means that users are already demanding (and getting) better
     standards conformance.  It doesn't come easy to many vendors since
     an "Open" playing field doesn't provide customer lockin.

  -  Another is that now we're seeing more alternatives, including some
     significant Open Source componentry (not just Mozilla).

     This means that vendors in the XML space won't be able to get away
     with as much.  (Watch out for the tactics some will take to cope...
     some bits of XML will get needlessly complex, as entry barriers for
     the newer vendors and perhaps as homes for more "browserisms".)

Surely there are other reasons, too -- like not giving in to despair!  ;-)

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 08:08:56 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:33 2004
Subject: public identifiers [Re: Referencing multiple DTD in an XMLdocument]
References: <Pine.BSI.3.96r.991104012329.13636H-100000@shell1.interlog.com>
Message-ID: <38213BFB.71057E7D@pacbell.net>

"Liam R. E. Quin" wrote:
> 
> On Wed, 3 Nov 1999, james anderson wrote:
> > David Brownell wrote:
> [...]
> > > I'd encourage you to use PUBLIC identifiers as well, so that
> > > local cached copies of those declarations can easily be used.
> >
> > Could someone expound further on this statement?
> 
> I would *discourage* you from using PUBLIC identifiers.
> Any system that bases caches on PUBLIC rather then SYSTEM identifiers
> for XML is broken.

Unless done as I later elaborated ... tho long-term caching on SYSTEM
identifiers can be substantially worse.  With PUBLIC ones there's the
expectation (from the document provider) that there be such a caching
mechanism ... and, very handy, a backup access method (SYSTEM id) is
provided in case the client doesn't grok the appropriate caching.


> The PUBILC keyword is there for backwards compatibility with SGML;
> its meaning in XML is not formally defined, and it's usually ignored.
> Therefore, if you want interoperability, simply forget it's there.

That's way too extreme.  One specific use for PUBLIC ids is called out
in the XML spec.  It's been used interoperably for almost 2 years now,
just counting the context of XML.  The suggestion was to use it.

There's the issue I noted (namespace of PUBLIC ids isn't specified),
but that can be dealt with.  Normally people use IDs that are also
legal SGML FPIs, and manage them like they manage FPIs.  Several other
schemes can work too -- it's all in how you use the identifiers.


It's not that PUBLIC ids are perfect ... but there is one substantial
problem that they can manage nicely, even with their current warts.
And that's providing a cheap (!) way to avoid network access for
external entities, notably for DTD components.  It's not just folk
with 28.8Kb modems that have such issues; those T1 lines also have
better uses for their limited capacity, and sometimes there's no net
connection at all.


> [...]
> 
> > I've yet to see a conclusive discussion of whether
> > dtd's (or for that matter schema) in the namespace age are stable. That is,
> > whether the same system uri will always identify an identical dtd/schema.
>
> They are not and it won't.

Doesn't that conflict with your advice to cache based on SYSTEM ids?

Clearly _some_ SYSTEM ids are stable enough to cache.  The trick is how
to know which those are ... hmm, that's part of why PUBLIC ids exist,
they can be "known" to be stable enough (if you know what the ID means;
I'd not advise automated guessing).


> <!NOTATION sh SYSTEM "/bin/sh -c">
> <!ENITY systemdate SYSTEM "/bin/date" NDATA sh>
>
> now systemdate returns a different value every tiem you use it (maybe
> evenwithin the same document, depending on the processor).
>
> This use of NOTATION is implied by the XML spec 

I never found such an implication, and I've been over the XML spec more
than once with a fine tooth comb.  You may be  thinking about PIs, though
they don't involve SYSTEM ids. ("<?sh /bin/date?>" that is.)

For that matter, that's an unparsed entity, so it will never be
included as (parsed) text in any XML document ... "systemdate"
can only be used as a value of a "NOTATION" attribute.  (Plus it
may well be that "/bin/date" isn't a valid relative URI, as it
must be to be used in a SYSTEM identifier.)


>	and by the SGML handbook,
> but since a docuemnt you recieve could just as easily use "format" or "rm",
> it's not a good idea, by the way.

It might be implied by the SGML handbook, but I'd surely hope
that in this day and age, nobody would contemplate desiging a
new system (e.g. one using XML) with security holes that big.


> > For example, would a processor be conforming if it were to, upon not finding a
> > resource "under" a public identifier, retrieve and expand the resource located
> > through the system identifier and cache the expanded (or even decoded result)
> > "under" the public identifier?
>
> You can do whatever you like with a public identifier -- it's undefined.

... undefined except for one specific usage, which is explicitly called
out (not just "implied") in the XML specification.


> No amount of wishful thinking will make it otherwise, for those who
> want to use it :-) sorry.

Umm ... your facts are generally a _lot_ better than that!

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 12:27:20 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:33 2004
Subject: XHTML 1.0 returned to HTML WG
References: <199911040134.UAA26222@hesketh.net> <m31za7atc1.fsf@localhost.localdomain>
Message-ID: <38217B89.FA37430B@prescod.net>

David Megginson wrote:
> 
>   The XML Namespace for HTML is http://www.w3.org/1999/11/HTML/ and
>   all names are lower case.
> 
> (or whatever suits).  Really -- just give us a Namespace, and we'll
> do stuff you barely dare to dream about.  That way, they can work on
> XHTML itself, modules, and all that at leisure.

Sure. Without a conformance specification, they could add in features
like BLINK, LOOP and SHIFT. I don't see how having dozens of groups
using HTML incompatibly is "progress". After all, we've been doing it
for five years now WITHOUT an HTML namespace.

Let me be concrete. Let's say you're developing a whizzy app to display
HTMLish documents. Now half-way through a document you run into:

<html:table><html:title/></html:table>

And thanks to the one line spec, this is now legal. What the hell do you
do? How does one write whizzy apps to work with the HTML namespace? And
if it isn't possible, then WHAT IS THE POINT OF THE NAMPESPACE?? If you
want to use HTML elements in your specs, DO IT...name elements in your
domain the same as HTML's. You can tell them that you have my full
blessing to do so. If you want to define a useful HTML namespace with
conformance requirements, I encourage you to do that also.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at mitretek.org  Thu Nov  4 15:33:38 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:16:33 2004
Subject: dynamic XML?
Message-ID: <004901bf26d9$e411e540$38a3f1ce@ls-.mitretek.org>


From: Dan Gunter <DKGunter@lbl.gov>
>I am working with some people who want to publish performance monitoring
>information in a standard exchange format. The details of the common
>vocabulary are still being discussed, but even at this early stage there
>are some technical questions about XML's use for such a task.
>
>One question is: assuming that the "things" being monitored, as well as
>the "characteristics" of the things being recorded, can change over
>time, is there a good way to dynamically add (even subtract) bits and
>pieces of the schema during the lifetime of the connection? I was
>thinking of something along the lines of a special couple of tags that
>tell the client to add/remove "things" or "characteristics" from its
>expected monitored events. Perhaps some of you have seen variations on
>this problem before?
>
>As a side note, XSchema looks more attractive than DTD's for this
>application (strict typing, among other things, would be nice).
>


I don't see that this has anything to do with DTDs or schemas.  As best I
understand you, you don't want to change the design or architecture of your
documents, you just what to change the details of the content.  This is not what
schemas are for.  If you want to change the list of monitored events, as you,
say you can just use some special tags to spell them out.  Your DTD can specify
that those specified tags are part of the document design, just like any other
tags.  The schema does not have to change just because you change the list of
items to be monitored.

Here is an analogy:  you wouldn't expect to switch from English to German  just
because you stopped monitoring parameter # 27, would you?  Well, you wouldn't
change the schema either.

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 15:35:23 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:33 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: David Brownell's message of "Wed, 03 Nov 1999 23:43:13 -0800"
References: <"199911040036117.SM00242"@Unknown> <38213911.7A0CD90A@pacbell.net>
Message-ID: <m3vh7ia2pd.fsf@localhost.localdomain>

David Brownell <david-b@pacbell.net> writes:

> > Curt Arnold sez:
> > 
> > > Namespace free XHTML would be fine with me.
> 
> Although I certainly suggested that at one point, I think _one_ is the
> preferable outcome, and the motivation for _zero_ namespaces would only
> have been to get XHTML out quicker than it appears can now happen.

Further to this point, the members' responses to the director are
confidential -- even those of us on W3C committees don't get to see
them -- but from what some members have told me unofficially, an XHTML
spec with zero Namespaces will not be any more successful than an
XHTML spec with three.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 15:35:41 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun  7 17:16:33 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <NBBBICMNIPCICMKJECCBKEAHDBAA.jelks@jelks.nu>
References: <3.0.32.19991103170850.00cfeb50@pop.intergate.ca>
Message-ID: <E11jN9s-0000md-00@romeo.ic.ac.uk>

At 09:58 PM 11/3/99 -0500, Jelks Cabaniss wrote:
>Tim Bray wrote:
>
>> Lots of people have good solid practical uses for namespaces.  Anyone who
>> thinks that HTML can go forward standing alone in glorious isolation and
>> never being mixed with another tag vocabulary Just Doesn't Get It.
>
>The How, not the What, is what's contentious.  Look at this list for the last
>several months.  Do we need that to hold back xHTML 1.0 for another three
months
>or more?

Nothing in any of this suggests it will be held back for 3+ months. The
group has been planning for a variety of contingencies, and is prepared to
turn this around very rapidly (read weeks, if even that, not months). 

Ann
--
Ann Navarro
Author: Effective Web Design: Master the Essentials, 
Due 10/99 - Mastering XML,12/99 HTML By Example, 2nd Ed.

Founder, WebGeek Communications http://www.webgeek.com/
Director, Online Education-HTML Writers Guild, http://www.hwg.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ypatil at kingston.hummingbird.com  Thu Nov  4 15:45:26 1999
From: ypatil at kingston.hummingbird.com (Yogita Patil)
Date: Mon Jun  7 17:16:33 2004
Subject: XSL Parser
Message-ID: <018701bf26db$93882650$1a02060a@andyne.com>

Does anybody know of an XSL Parser for C++ ? 
Thanks,
Yogita.

Yogita Patil
Software Developer
Hummingbird Communications Ltd.
Decision Portals Division.
552 Princess Street.
Kingston, Ontario.
K7L-1C7
(613) 548-4355 Ext. 1540

Canada.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991104/5e45d2b0/attachment.htm
From tpassin at mitretek.org  Thu Nov  4 15:48:48 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:16:33 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <004401bf26d8$ff6d2e40$38a3f1ce@ls-.mitretek.org>


From: Paul Prescod


>David Megginson wrote:
>>
>>   The XML Namespace for HTML is http://www.w3.org/1999/11/HTML/ and
>>   all names are lower case.
>>
>> (or whatever suits).  Really -- just give us a Namespace, and we'll
>> do stuff you barely dare to dream about.  That way, they can work on
>> XHTML itself, modules, and all that at leisure.
>
>Sure. Without a conformance specification, they could add in features
>like BLINK, LOOP and SHIFT. I don't see how having dozens of groups
>using HTML incompatibly is "progress". After all, we've been doing it
>for five years now WITHOUT an HTML namespace.
>
>Let me be concrete. Let's say you're developing a whizzy app to display
>HTMLish documents. Now half-way through a document you run into:
>
><html:table><html:title/></html:table>
>
>And thanks to the one line spec, this is now legal. What the hell do you
>do? How does one write whizzy apps to work with the HTML namespace? And
>if it isn't possible, then WHAT IS THE POINT OF THE NAMPESPACE?? If you
>want to use HTML elements in your specs, DO IT...name elements in your
>domain the same as HTML's. You can tell them that you have my full
>blessing to do so. If you want to define a useful HTML namespace with
>conformance requirements, I encourage you to do that also.
>
> Paul Prescod
>


It seems to me that using one of the (3 - or is it to be 1?) xhtml namespaces
could basically have three reasons.  The other posts are of course talking about
them, but I thought I'd just condense them together in one place.

1) To inform the receiving html processor which variety of html is in the
document. We already have a declaration for that.  As other posts have
mentioned, it is often ignored by existing browsers.  No namespace is required,
we just output the right declaration as Rev. Bob is doing.

2) We want to tell our own processor, the one that will produce the document,
which style of html to output.  Of course, there are zillions of ways to do
this.  The hard-core xml-ish way would presumably be to use an xsl or xslt
stylesheet to create the xhtml output.  Here, it would make good sense to use
different namespaces to inform the processor what to output.  But observe - we
would use the namespace in the stylesheet, not in the source!  If we want to
produce another flavor of xhtml output, we use a stylesheet that declares a
different namespace.  This is a classic use for a namespace.  But the namespace
does not need to appear in the output, only in the stylesheet!  The output could
include the html flavor declaration if desired.

3) To inform some (non-browser) receiving processor which flavor of html is in
the document.  In other words, if I want to do some xml-like activity - like
extracting data from the xhtml document - by parsing the xhtml, constructing a
tree, using XPATH or DOM, etc., I might need to know this information.  Now here
is the main reason we might want to use xhtml, I think.  It lets us use xml
tools to get at the parts of the html document for other proposes than browsing.
It seems like the existing html declaration would be adequate for this too, just
as it is for case 1).

So neither for purpose 1), 2), or 3)  is there any reason to include the
namespace in the output document.  The only time you would need a namespace in
the result document would be if you wanted to mix and match xhtml styles within
the same document.  The namespace would let you handle that.  I suggest that
this is bogus, there is no practical need to allow for this mixing and matching.

On the other hand, it seems like there could be valid reasons for wanting to
declare appropriate DOCTYPEs in the xhtml document.

Conclusions:  there is no value in including an xhtml namespace - as opposed to
a DOCTYPE declaration - in the actual xhtml document. There is potential value
in defining these namespaces for use by an xslt processor, just as xslt already
has some escape mechanisms that let it output html rather than only strict xml.
More than one DOCTYPEs could be useful for xhtml.

How am I doing here? is there something significant that I missed?

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov  4 16:19:42 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:34 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: "Thomas B. Passin"'s message of "Thu, 4 Nov 1999 10:26:42 -0500"
References: <004401bf26d8$ff6d2e40$38a3f1ce@ls-.mitretek.org>
Message-ID: <m3aeou9qnl.fsf@localhost.localdomain>

"Thomas B. Passin" <tpassin@mitretek.org> writes:

> It seems to me that using one of the (3 - or is it to be 1?) xhtml
> namespaces could basically have three reasons.  The other posts are
> of course talking about them, but I thought I'd just condense them
> together in one place.

[snip]

None of those points looks very familiar to me, and they certainly
have not come up much in discussions.  I hear two main arguments for
HTML Namespaces:

1. To allow processors to distinguish non-HTML markup in HTML
   documents (text/html); and

2. To allow processors to distinguish HTML markup in general XML
   documents (text/xml).

I care most about (2), but others care more about (1).  They both boil 
down to the ability to make an HTML/not-HTML distinction easily.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dhunter at Mobility.com  Thu Nov  4 17:07:41 1999
From: dhunter at Mobility.com (Hunter, David)
Date: Mon Jun  7 17:16:34 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <805C62F55FFAD1118D0800805FBB428D02BC0079@cc20exch2.mobility.com>

Thank you for posting this here, Tim.  Without getting into the "one vs.
three vs. none" debate [yet], I'm glad the issue will get more consideration
before the spec is "recommended", since the, ahem, heated debate never
really seemed settled to me.

I am also hoping, after reading the post by Ann Navarro, that a revised
version of the spec will be ready soon.  Although I didn't want to see the
spec go on as it was, I also don't want it to be held up for a long time
either, because I think we all want XHTML to be successful, so that it can
take over for HTML as soon as possible.  ;-)

-----Original Message-----
From: Tim Berners-Lee [mailto:timbl@w3.org]
Sent: Wednesday, November 03, 1999 4:34 PM
To: xml-dev
Subject: Fw: XHTML 1.0 returned to HTML WG


FYI - tim

<big-snip/>

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



From matthew at praxis.cz  Thu Nov  4 17:11:21 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:16:34 2004
Subject: XML as a top-level media type (was Re: Fw: XHTML 1.0 returned to HTML 
 WG)
References: <002b01bf2643$1a739530$2a7b0a0a@ridge.w3.org>
Message-ID: <3821BDEA.136B9DF5@praxis.cz>

Tim Berners-Lee wrote:
> >A few respondents were also concerned about the use of the text/xml
> >media type for delivering xHTML, considering this to be "premature".
> >If a document conforming to XML 1.0 and XML Namespaces is not to be
> >considered "text/xml", this raises an important issue as to what is.

I am curious to know whether the idea of using "xml" as the top-level
media type, rather than the subtype, has occurred to anyone. This seems
apt to me because XML applications are going to need both the
information that a given media type is XML and information about the
precise schema that the media type conforms to. This is, I suspect, why
neither the "text/xml" or "text/xhtml" variants seem entirely
satisfactory. In my opinion "xml/xhtml" (and the precedent thus set)
would solve all these problems and enable applications to work with XML
documents both generically and in a way specific to a given schema. On
the other hand, I have no idea what the implications of creating an
entirely new top-level media type are.

Matthew

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



From Curt.Arnold at hyprotech.com  Thu Nov  4 17:31:16 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:16:34 2004
Subject: Application profiles Re: XHTML 1.0 returned to HTML WG
Message-ID: <61DAD58E8F4ED211AC8400A0C9B4687341547A@THOR>

In my post on the XHTML 1.0 returning to HTML WG thread.  I said some things
from the hip that I have now rethought.

Basically, I think my original statements that the controversy was due to
misusing namespaces to indicate a particular profile of capabilities of a
processor was correct and that there has not been a good generic XML
solution to indicate what capability profiles that a document conforms to.

I had suggested that this seemed to be a clear case of trying to communicate
a hint to the eventual processor (which I still believe) and that seemed to
be an appropriate use of a Processing Instruction (which I have rethought).
The problems with using a PI is that it is not scoped (generic XML problem)
and that it would be displayed by existing some HTML processors.

How about defining a profiles attribute for the html element that is a space
delimited list of uri's that identify the application profiles that the html
element adheres to?  URI's could be established that indicate the three
application profiles that correspond with frameset, strict and transitional.
These URI's would be like namespaces in that they do not imply that their is
a resource associated with that URI that can be used to validate whether the
element adheres to that profile.

So you end up with three loosely coupled declarations:

1) A Document Type Declaration that indicates a resource that can be used to
validate the document.  Three distinct DTD's could be published
corresponding to three proposed namespaces.
2) One Namespace URI that identifies the specific tags as to be interpreted
in the XHTML namespace
3) Declarations that the html element adheres to zero or more specific
application profiles.

p.s. This suggested to me that it would be good to add types for space
delimited lists of non-space containing datatypes (reals, uris, integers,
decimals) to the list of built in types in XML Schemas.  Or to provide a
construct to define a datatype as a list of other datatypes.

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



From Cem.Redif at Xpedior.com  Thu Nov  4 18:00:40 1999
From: Cem.Redif at Xpedior.com (Cem Redif)
Date: Mon Jun  7 17:16:34 2004
Subject: Content Management with BroadVision and XML
Message-ID: <38223A28.383BD803@Xpedior.com>

Hi,

Does anyone know of any 3rd party vendor products that have Content
Management for XML to work under the BroadVision's content management
framework.

Regards,
Cem.


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



From Cem.Redif at Xpedior.com  Thu Nov  4 18:04:06 1999
From: Cem.Redif at Xpedior.com (Cem Redif)
Date: Mon Jun  7 17:16:34 2004
Subject: Data Sharing between Trading Partners in BroadVision
Message-ID: <38223B08.54281648@Xpedior.com>

Hi,

Does anyone know of any 3rd party vendor products that have the ability
to share data between trading partnets (for XML of course) to work under
the BroadVision's current communications framework.

Regards,
Cem.


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



From ypatil at kingston.hummingbird.com  Thu Nov  4 21:26:35 1999
From: ypatil at kingston.hummingbird.com (Yogita Patil)
Date: Mon Jun  7 17:16:34 2004
Subject: Memory file
Message-ID: <01cf01bf270b$374b0490$1a02060a@andyne.com>

Can we give a memory file as input to IBM XML4C's DOM Parser ?

Thanks in advance.
Yogita.

Yogita Patil
Software Developer
Hummingbird Communications Ltd.
Decision Portals Division.
552 Princess Street.
Kingston, Ontario.
K7L-1C7
(613) 548-4355 Ext. 1540

Canada.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991104/eb8edc3d/attachment.htm
From simonstl at simonstl.com  Thu Nov  4 21:42:35 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:34 2004
Subject: XML as a top-level media type (was Re: Fw: XHTML 1.0
  returned to HTML  WG)
In-Reply-To: <3821BDEA.136B9DF5@praxis.cz>
References: <002b01bf2643$1a739530$2a7b0a0a@ridge.w3.org>
Message-ID: <199911042142.QAA15733@hesketh.net>

At 06:10 PM 11/4/99 +0100, Matthew Gertner wrote:
>I am curious to know whether the idea of using "xml" as the top-level
>media type, rather than the subtype, has occurred to anyone. This seems
>apt to me because XML applications are going to need both the
>information that a given media type is XML and information about the
>precise schema that the media type conforms to. This is, I suspect, why
>neither the "text/xml" or "text/xhtml" variants seem entirely
>satisfactory. In my opinion "xml/xhtml" (and the precedent thus set)
>would solve all these problems and enable applications to work with XML
>documents both generically and in a way specific to a given schema. On
>the other hand, I have no idea what the implications of creating an
>entirely new top-level media type are.

This has been hashed out on ietf-xml-mime - see the archives at
http://www.imc.org/ietf-xml-mime/

Some key threads:
Re: Perhaps we need an XML registration tree (was Re: Parameters for
top-level XML media types?)
RE: Top-level media type xml desirable? (WAS: RE: Parameters for top-level
XML media types?)
Re: Parameters for top-level XML media types?

I took a whack at a suffix solution - see the Modest Proposal thread.

That suffix solution is in the current Internet Draft - comments are
welcome on the ietf-xml-mime list.  (The draft is at
http://www.imc.org/draft-murata-xml).

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  4 23:46:03 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:34 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <38217B89.FA37430B@prescod.net>
Message-ID: <003901bf271e$fe5a5be0$099918d1@docuverse1>

><html:table><html:title/></html:table>
>
>And thanks to the one line spec, this is now legal. What the 

There is an arguable common sense when we refer to a document as
'HTMLish' and I believe your example violates that.  If people are
going to abuse namespace like that, it is our job to knock some
sense into them rather than wrap them up in diapers and ducktape
everything with foams.  IMHO, I must say.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Jabjanic at ipivot.com  Fri Nov  5 00:01:17 1999
From: Jabjanic at ipivot.com (John Abjanic)
Date: Mon Jun  7 17:16:34 2004
Subject: XSL Parser
Message-ID: <A1DB3C84CF25D3118493005004AD2F3D034298@exchange.ipivot.com>

IBM has plans to support XSL in their XML4c  parser, which uses C++.
They have not identified when it will available though.
 
John Abjanic
IPivot, an Intel  Company
http://www.ipivot.com <http://www.ipivot.com> 
  

-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
Yogita Patil
Sent: Thursday, November 04, 1999 7:45 AM
To: xml dev mailing list
Subject: XSL Parser


Does anybody know of an XSL Parser for C++ ? 
Thanks,
Yogita.
 
Yogita Patil
Software Developer
Hummingbird Communications Ltd.
Decision Portals Division.
552 Princess Street.
Kingston, Ontario.
K7L-1C7
(613) 548-4355 Ext. 1540
 
Canada.


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



From jonsmirl at mediaone.net  Fri Nov  5 00:27:29 1999
From: jonsmirl at mediaone.net (Jon Smirl)
Date: Mon Jun  7 17:16:35 2004
Subject: XSL Parser
References: <018701bf26db$93882650$1a02060a@andyne.com>
Message-ID: <025c01bf2724$50b7ec40$0200a8c0@ne.mediaone.net>

>From: Yogita Patil 
>Does anybody know of an XSL Parser for C++ ? 


http://lxr.mozilla.org/seamonkey/source/extensions/transformiix/

Jon Smirl
jonsmirl@mediaone.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991105/12beb9ec/attachment.htm
From david at megginson.com  Fri Nov  5 00:46:37 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:35 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: "Don Park"'s message of "Thu, 4 Nov 1999 15:47:41 -0800"
References: <003901bf271e$fe5a5be0$099918d1@docuverse1>
Message-ID: <m3zowtlqb4.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

(that Paul Prescod writes that)

> ><html:table><html:title/></html:table>
> >
> >And thanks to the one line spec, this is now legal. What the 

Actually, it's neither legal nor illegal, simply unspecified.

(and Don writes)

> There is an arguable common sense when we refer to a document as
> 'HTMLish' and I believe your example violates that.  If people are
> going to abuse namespace like that, it is our job to knock some
> sense into them rather than wrap them up in diapers and ducktape
> everything with foams.  IMHO, I must say.

Just so -- in the end, it's simple peer pressure that forces
interoperability.  That's a terrifying thought for standards writers,
but it's also the explanation for why scarcely any of the 18 W3C
Recommendations at 

  http://www.w3.org/TR/

have actually been widely implemented so far (CSS1, XML, and maybe DOM
-- anything else?).  We won't even start counting the WDs...

It's nice, then, that there's a lot of pressure for implementors to
conform to the XML REC, but things don't always work that way: after a
few years' observation, we can safely say that there is little peer
pressure for industry to pay much attention to the W3C's HTML specs,
since there's only a miniscule amount of conformant HTML 3.* or 4.*
out there.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Fri Nov  5 01:03:00 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:35 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <m3vh7ia2pd.fsf@localhost.localdomain>
Message-ID: <NBBBICMNIPCICMKJECCBIEBLDBAA.jelks@jelks.nu>

David Megginson wrote:

> Further to this point, the members' responses to the director are
> confidential -- even those of us on W3C committees don't get to see
> them -- but from what some members have told me unofficially, an XHTML
> spec with zero Namespaces will not be any more successful than an
> XHTML spec with three.

Well that settles that, doesn't it?  

:)

/Jelks


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



From sguthery at rcn.com  Fri Nov  5 02:35:46 1999
From: sguthery at rcn.com (Scott Guthery)
Date: Mon Jun  7 17:16:35 2004
Subject: WML vs. XHTML
Message-ID: <056001bf279a$f91f2d00$6e7d06d1@aa.net>

Anybody care to compare and contrast XHTML and WML?

Thanks much.

Cheers, Scott

******************* Smart Card Developer's Kit *******************
Scott Guthery                                     sguthery@rcn.com
Voice: 617 964 1798    Mobile: 617 290 3963      FAX: 617 795 1630
*********************** http://www.scdk.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From steve at redsquare.com.au  Fri Nov  5 03:16:49 1999
From: steve at redsquare.com.au (Steve Baty)
Date: Mon Jun  7 17:16:35 2004
Subject: WML vs. XHTML
Message-ID: <029c01bf273b$d45a3aa0$0f044ccb@kit.redsquare.com.au>

Scott,

In a nutshell, XHTML is the conversion and modularisation of HTML 4.0 in XML
1.0. It is a work in progress, as can be seen by the recent discussion on
its return to the W3C. Others here will give you a much more insightful
description of XHTML.

WML is an implementation of XML 1.0 for use on handheld, wireless devices.
It is a core part of the Wireless Application Protocol and is currently
being implemented in a broad range of internet - based applications. WML is
the language of choice for WAP-enabled devices from Nokia, Ericsson etc
although not the only choice (HDML being an alternative).

WAP is in the process of being rolled out in Australia and is generating a
great deal of media coverage as the Next Big Thing.

Hope this helps

Steve Baty
Technical Designer
Red Square Productions
http://www.redsquare.com.au
steve@redsquare.com.au
Ph: +612 9519 4599
Fax: +612 9519 4699
Member of the HTML Writers Guild
-----Original Message-----
From: Scott Guthery <sguthery@rcn.com>
To: xml <xml-dev@ic.ac.uk>
Date: Friday, 05 November 1999 13:58
Subject: WML vs. XHTML


>Anybody care to compare and contrast XHTML and WML?
>
>Thanks much.
>
>Cheers, Scott
>
>******************* Smart Card Developer's Kit *******************
>Scott Guthery                                     sguthery@rcn.com
>Voice: 617 964 1798    Mobile: 617 290 3963      FAX: 617 795 1630
>*********************** http://www.scdk.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From AlanM at SYNECTICS.Soft.net  Fri Nov  5 05:01:14 1999
From: AlanM at SYNECTICS.Soft.net (Alan Menezes)
Date: Mon Jun  7 17:16:35 2004
Subject: WML vs. XHTML
Message-ID: <1F4436D26763D2119B8800A0C9DE689797E6C5@MAIL>

Hi Steve,
I have heard of both XHTML and WML and their uses.
Now can you please elaborate on the HDML that you have mentioned.
Thanks and Regards,
Alan

> -----Original Message-----
> From:	Steve Baty [SMTP:steve@redsquare.com.au]
> Sent:	Friday, November 05, 1999 8:44 AM
> To:	xml-dev@ic.ac.uk
> Subject:	Re: WML vs. XHTML
> 
> Scott,
> 
> In a nutshell, XHTML is the conversion and modularisation of HTML 4.0 in
> XML
> 1.0. It is a work in progress, as can be seen by the recent discussion on
> its return to the W3C. Others here will give you a much more insightful
> description of XHTML.
> 
> WML is an implementation of XML 1.0 for use on handheld, wireless devices.
> It is a core part of the Wireless Application Protocol and is currently
> being implemented in a broad range of internet - based applications. WML
> is
> the language of choice for WAP-enabled devices from Nokia, Ericsson etc
> although not the only choice (HDML being an alternative).
> 
> WAP is in the process of being rolled out in Australia and is generating a
> great deal of media coverage as the Next Big Thing.
> 
> Hope this helps
> 
> Steve Baty
> Technical Designer
> Red Square Productions
> http://www.redsquare.com.au
> steve@redsquare.com.au
> Ph: +612 9519 4599
> Fax: +612 9519 4699
> Member of the HTML Writers Guild
> -----Original Message-----
> From: Scott Guthery <sguthery@rcn.com>
> To: xml <xml-dev@ic.ac.uk>
> Date: Friday, 05 November 1999 13:58
> Subject: WML vs. XHTML
> 
> 
> >Anybody care to compare and contrast XHTML and WML?
> >
> >Thanks much.
> >
> >Cheers, Scott
> >
> >******************* Smart Card Developer's Kit *******************
> >Scott Guthery                                     sguthery@rcn.com
> >Voice: 617 964 1798    Mobile: 617 290 3963      FAX: 617 795 1630
> >*********************** http://www.scdk.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> >unsubscribe xml-dev
> >To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Fri Nov  5 05:01:07 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:36 2004
Subject: WML vs. XHTML
In-Reply-To: <029c01bf273b$d45a3aa0$0f044ccb@kit.redsquare.com.au>
Message-ID: <NBBBICMNIPCICMKJECCBEEBPDBAA.jelks@jelks.nu>

Steve Baty wrote:

> WML is an implementation of XML 1.0 for use on handheld, wireless devices.
> It is a core part of the Wireless Application Protocol and is currently
> being implemented in a broad range of internet - based applications. WML is
> the language of choice for WAP-enabled devices from Nokia, Ericsson etc
> although not the only choice (HDML being an alternative).
>
> WAP is in the process of being rolled out in Australia and is generating a
> great deal of media coverage as the Next Big Thing.

Indeed, and Rohit Khare nicely debunks this media hoopla in his article "W*
Effect Considered Harmful":

	http://www.4k-associates.com/IEEE-L7-WAP-BIG.html


/Jelks




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



From dalapeyre at mulberrytech.com  Fri Nov  5 05:46:58 1999
From: dalapeyre at mulberrytech.com (Deborah Aleyne Lapeyre)
Date: Mon Jun  7 17:16:36 2004
Subject: New Technology Nursery for MT'99/XML'99
Message-ID: <v03020909b447d7ac0c60@[199.174.193.110]>

Attention People who write software and want it seen
(e.g., academics and shareware writers):

At the GCA December conferences in Philadephia, tabletops
will be available in the Exhibit Hall to show your software.
Below is GCA's pitch.  Please consider showing your wares!
(Information about the conferences is available at
   http://www.gca.org)

---------------  GCA Announcement -------------------------

The New Technology Nursery is a venue for the display of pre-release
commercial tools, free tools, and shareware tools.  In this protected
"nursery" environment, GCA is helping to nurture the tools of tomorrow.  In
the New Technology Nursery, users have the opportunity to get previews of
future products and free tools, and developers can get user feedback on tools
that are not yet ready to release.

This is free!
If you want to display your free or pre-release software in the New
Technology Nursery (a table and electric power will be provided) contact
Julie Desmond at jdesmond@gca.org.

---------------  GCA Announcement -------------------------

--Debbie



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



From steve at redsquare.com.au  Fri Nov  5 05:47:47 1999
From: steve at redsquare.com.au (Steve Baty)
Date: Mon Jun  7 17:16:36 2004
Subject: WML vs. XHTML
Message-ID: <02f501bf274d$697fee20$0f044ccb@kit.redsquare.com.au>

One of the early developers of WAP technology - they created an early WAP
gateway and emulator, called, respectively, UP.Link and UP.Phone - came up
with this language for handheld devices. (I apologise now for any inaccuracy
in this information - it has been over 12 mths since I looked at HDML.)

The device worked with a proprietary markup language called Handheld Device
Markup Language (HDML). It is not an XML language, although it is tag based.
I think this was the reason it was overlooked in favour of WML as the
standard for WAP devices.

I have included a snippet of code from their login page - which is shipped
with the emulator as a sample.
==============================
<HDML VERSION=3.0 TTL=0 MARKABLE=FALSE>

    <-- ACTIVITY: Login Activity -->

    <-- All input values must be at least 6 characters or more -->
    <-- Using "m" instead of "M" defaults entry to lowercase   -->

    <ENTRY NAME=home KEY=hostname FORMAT=mmmmmm*m>
   <ACTION TYPE=ACCEPT TASK=GOSUB VARS=host=$(hostname)
  RECEIVE=user;passwd NEXT=#results DEST=#passcard1>
  Host name:
    </ENTRY>

    <DISPLAY NAME=results>
 <ACTION TYPE=ACCEPT TASK=RETURN LABEL=Done>
 <LINE>Accepted:
 <BR>Name=$(user)
 <BR>Pswd=$(passwd)
    </DISPLAY>

    <-- ACTIVITY:  Enter a name and password -->

    <ENTRY NAME=passcard1 KEY=name FORMAT=mmmmmm*m>
 <ACTION TYPE=PREV TASK=GO DEST=#cancelshield>
 <ACTION TYPE=ACCEPT TASK=GO DEST=#passcard2>
 $(host)
 <BR>User Name:
    </ENTRY>

    <ENTRY NAME=passcard2 KEY=password FORMAT=mmmmmm*m NOECHO=TRUE>
 <ACTION TYPE=ACCEPT TASK=GO DEST=#confirmshield>
 $(host)
 <BR>Password:
    </ENTRY>

    <DISPLAY NAME=cancelshield>
 <ACTION TYPE=ACCEPT LABEL=Yes TASK=CANCEL>
 <ACTION TYPE=SOFT1 LABEL=No TASK=GO DEST=#passcard1>
 Cancel login?
    </DISPLAY>

    <DISPLAY NAME=confirmshield>
 <ACTION TYPE=ACCEPT TASK=RETURN LABEL=Yes RETVALS=$(name);$(password)>
 <ACTION TYPE=SOFT1 LABEL=No TASK=PREV>
 Commit login?
    </DISPLAY>

</HDML>
==============================
Cheers

Steve Baty
Technical Designer
Red Square Productions
http://www.redsquare.com.au
steve@redsquare.com.au
Ph: +612 9519 4599
Fax: +612 9519 4699
Member of the HTML Writers Guild
-----Original Message-----
From: Alan Menezes <AlanM@SYNECTICS.Soft.net>
To: Steve Baty <steve@redsquare.com.au>
Cc: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk>
Date: Friday, 05 November 1999 16:02
Subject: RE: WML vs. XHTML


>Hi Steve,
>I have heard of both XHTML and WML and their uses.
>Now can you please elaborate on the HDML that you have mentioned.
>Thanks and Regards,
>Alan



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



From rev-bob at gotc.com  Fri Nov  5 06:07:45 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:36 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <199911040530992.SM00242@Unknown.>

> > Depends on what you mean by that; I see the dangerous potential there
> > of descending into the same morass we currently have with HTML, where
> > we theoretically go by the DTD,
> 
> I never thought that HTML <!DOCTYPE ...> declarations were ever
> usable for any purpose other than content providers to validate, in
> order to work on more browsers.  How could they be?  I think that
> HotJava once tried to validate -- and gave up quickly because so
> many sites _only_ produce illegal HTML.

Conversely, I always found !DOCTYPE-based validation to be useless in the context of 
making pages work on more browsers.  Sometimes, you have to know when to go 
outside of the spec - especially when you consider all the browser-specific junk 
introduced in the 2.x/3.x browsers, the backstepping done between HTML 3.2 and 4.0 
regarding presentation tags, etc.  It's all well and good to say "use CSS for presentation" 
in theory, but the reality is that there are still a lot of old browsers out there that don't 
know CSS from CQD.  (Last time I checked, my XML pages checked out as XHTML 
compliant and my HTML pages *almost* check out.  There's one element on every 
HTML page that isn't spec-legal, and it's there for old browser support.  C'est la vie.)

That's why I'm looking forward to widespread adoption of an XML/XHTML spec - it's 
a fresh start.  No browser that is XHTML-compliant should require "old browser tricks" 
- it's a new platform, and because time has gone by, the bottom level of that platform 
can be a great deal higher than the bottom level of the HTML platform.  This is a good 
thing.  With HTML, you have to use tables for some types of layout, because they work 
on a wide variety of browsers.  Yes, CSS is a better option in theory, but the real 
installed UA base doesn't support it.  It's starting to, but it ain't there yet.  With 
X(HT)ML, you know that any browser capable of parsing the pages can handle CSS - 
so you don't have to use the workarounds.  However (to return to the original point), if 
some tangible form of control doesn't exist on what tags are accepted and how DTD 
interaction works, it won't be long before we're back at the drawing board, wondering 
where we went wrong.

It's the difference between theory and reality.  If the theory of XML and its X-siblings 
can be realized, the reality of instant support for new specs just might be in our grasp.  
That's one hell of a big IF, though.

> >	 but in actuality, it's anybody's guess what browserisms a random
> > user agent will support.  Witness the spotty support CSS1 and CSS2 have,
> > not to mention HTML4 itself.
> 
> Namespaces are for distinguishing an XHTML "table" from furniture, not
> for nuancing IE4/Mac table browserisms (bugs) from NN4.61/Linux ones.

You miss my point; I was contrasting the theory of a valid HTML DTD which should 
work on any HTML browser with the reality of incomplete support and assorted 
browserisms.  I was not by any stretch trying to equate namespaces with browserisms.

> > why should we expect that the UAs we will have for XML will do any better?
> 
> Better in what respect -- being less buggy?  Two things come to mind:

Better in terms of support.  Better meaning "if the spec defines it, the UA will understand 
it".  Better meaning that the developer can actually go by the spec, instead of having to 
keep an armada of browsers on hand to ensure that everything works as it should.  
Better meaning that the theory of the spec actually aligns somewhat with the reality of 
the UAs.  Clear enough?

>   -  One is that so many developers understand the damage that comes from
>      HTML standards being so thoroughly ignored ... which wasn't widely
>      understood as the damage was being created.  XML has "draconian"
>      error handling (no display if it's not well formed!), which is a
>      big step forward (though it only goes so far).

That's something I really like about XML - although, as noted, it only goes so far.

>      This means that users are already demanding (and getting) better
>      standards conformance.  It doesn't come easy to many vendors since
>      an "Open" playing field doesn't provide customer lockin.

Translation: "Netscape and Microsoft like to add their own proprietary tags."  Perhaps 
with the advent of XML, they'll realize that the better path to dominance is in enhancing 
the usability features that Joe Average actually notices, instead of trying to fragment the 
Web by bribing developers into using proprietary tags.

Take a look at the NeoPlanet browser for a minute.  It's a shell.  By using the IE libraries 
to do the rendering work, they're free to concentrate on the interface - *and it works*.  
If their Gecko plugin was more stable (which I blame on the alpha status of the Gecko 
code), I'd make NeoPlanet my default browser in an instant - because I can switch 
rendering engines without losing user interface features, mailboxes, or anything else.  
One user, one shell, multiple engines - that's what I call customer lockin.  At least, for 
this customer....

>   -  Another is that now we're seeing more alternatives, including some
>      significant Open Source componentry (not just Mozilla).

Hey, as long as I can get data on more UAs, more power to 'em.  The only reason I 
don't provide more granular support now is that I just don't have the data.  ("How's that 
look on Opera?"  "I dunno.  I don't get many Opera hits, so the registration cost isn't 
worth it.  I'll treat it as base-level and see what happens.")

>      This means that vendors in the XML space won't be able to get away
>      with as much.  (Watch out for the tactics some will take to cope...
>      some bits of XML will get needlessly complex, as entry barriers for
>      the newer vendors and perhaps as homes for more "browserisms".)

Some bits of anything will always be needlessly complex.  That's part of what makes it 
fun, sometimes.  :)

> Surely there are other reasons, too -- like not giving in to despair!  ;-)

As those of you who've visited my site probably know by now, I don't give in to despair; 
I retrofit it as rage and use it as fuel.  (And I know some of you have been by; I saw the 
spike in the logs.  For those using Netscape who had problems Wednesday, the stray 
greater-than symbol has been eradicated and the pages work again.)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


*---------------------------------------------------------*
       E-Mail Delivery By VEI Internet Mail Services
   http://www.veiinternet.com - $14.95 Unlimited Internet

       Visit The New VEI Stores Open For Christmas:
       VEI DVD Store - http://vei.vstoredvds.com/
       VEI Book Store - http://veibooks.vstorebooks.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From XMLDevGuy at aol.com  Fri Nov  5 06:31:57 1999
From: XMLDevGuy at aol.com (XMLDevGuy@aol.com)
Date: Mon Jun  7 17:16:36 2004
Subject: WML vs. XHTML
Message-ID: <0.c4b12b3d.2553d3b5@aol.com>

WML is a more advanced than HDML as it includes WMLScripting (for storing 
variables across multiple cards and access to special phone features), 
following the DTD for WML pretty much gives you everything that one needs to 
know for creating a Deck.  A Deck is also an XML Doc.  

Being an avid DHTML developer, is XHTML worth looking @ at this point?  

Also, Im assuming with XML:XSL that an implementation could be make for WML 
easily (with the exception of the events).  I wrote a WML java package a few 
months ago with simple Deck and Card classes and has worked ok, but Im very 
interested in simply dropping it for XML:XSL style.  Make sense?

- Jon

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



From XMLDevGuy at aol.com  Fri Nov  5 06:33:59 1999
From: XMLDevGuy at aol.com (XMLDevGuy@aol.com)
Date: Mon Jun  7 17:16:36 2004
Subject: IBM's ElementHandler
Message-ID: <0.da3d2c33.2553d431@aol.com>

Does anyone know any pros vs. cons for using it?  Im thinking about 
experimenting with it a little to do some HTML alterations and XML 
alterations but wanted to see if anyone was using it...

- Jon

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



From asjoshi at hss.hns.com  Fri Nov  5 07:43:10 1999
From: asjoshi at hss.hns.com (asjoshi@hss.hns.com)
Date: Mon Jun  7 17:16:36 2004
Subject: a newbie question..
Message-ID: <65256820.00256A16.00@sandesh.hss.hns.com>



Hi  all!!

I am Ashutosh Joshi - a software developer in India -

For out WAP prototype, we need to make a WML to WBXML converter..

Any pointers on how I may be able to do this as efficiently as possible..??


Ashutosh



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



From mparul at in.ibm.com  Fri Nov  5 08:28:45 1999
From: mparul at in.ibm.com (mparul@in.ibm.com)
Date: Mon Jun  7 17:16:36 2004
Subject: Using a math element in a DTD
Message-ID: <CA256820.002E80D5.00@d73mta05.au.ibm.com>

Hi,

I want to define an element in my own DTD that will be a "math" element tag
- from MathML DTD.
e.g

this is my foo.dtd
<!ELEMENT foo (bar, value)>
<!ELEMENT foo (math)>
<!ELEMENT bar (#PCDATA)>

here math is an element tag from MathML DTD available at the w3.org site.

How to reflect that the math element is from the MathML dtd?

Thanks
Parul



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



From varun at chennai.tcs.co.in  Fri Nov  5 09:12:26 1999
From: varun at chennai.tcs.co.in (V Arun Kumar)
Date: Mon Jun  7 17:16:36 2004
Subject: xll
Message-ID: <65256820.00326E72.00@MAILSERVER2.chennai.tcs.co.in>



could anyone point me to some good resources regarding xll
  is it being supported by IE5
  thanx



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



From rgl at decisionsoft.com  Fri Nov  5 10:11:36 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:16:36 2004
Subject: WML vs. XHTML
In-Reply-To: <0.c4b12b3d.2553d3b5@aol.com>
Message-ID: <Pine.LNX.4.10.9911051006320.6476-100000@localhost.localdomain>

On Fri, 5 Nov 1999 XMLDevGuy@aol.com wrote:

> Also, Im assuming with XML:XSL that an implementation could be make for WML 
> easily (with the exception of the events).  I wrote a WML java package a few 
> months ago with simple Deck and Card classes and has worked ok, but Im very 
> interested in simply dropping it for XML:XSL style.  Make sense?

We've done some preparatory work on dynamically generating WML files from
XML data using XML Script (www.xmlscript.org); this could obviously be
extended to converting XHTML to WML on the fly. The general principle
works absolutely fine - the difficult bit is the logic of displaying data
on a very small screen.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


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



From rev-bob at gotc.com  Fri Nov  5 10:45:00 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:36 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <199911050544808.SM00154@Unknown.>

> > Okay, maybe I'm a little brighter than the HTML coders you're thinking of, but I
> > spawned an XHTML version of my site with fairly little trouble.
> 
> [multi-step saga deleted]

Wow...my process qualifies as a saga.  Cool.  Not bad for about a week-long "when I 
have time" project.
 
> For those who are going to do this, I recommend the use of HTML Tidy, an
> open-source program that cleans up junk HTML (as produced by the products of a
> certain corporation, or by "HTML coders") and has a switch to generate XML.

I considered that option, but it had one problem I just couldn't overcome.  See, my pages 
are assembled on the fly.  The core part is one document, but common fragments are 
stored in a database and in various include files.  Add in the pre-server and server-side 
scripting languages, and I really don't think HTML Tidy could handle it.

But, there again, perhaps this is a more advanced (or maybe just more complex) system 
than the aforementioned "HTML coders" are supposedly using.  Yes, if someone's idea 
of web design is firing up FrontPage or PageMill, HTML Tidy will do them a world of 
good...but once you get into database connectivity and server-side scripting languages 
like iHTML, that utility will not help you.

Incidentally, on something completely unrelated - as I read the HTML4 spec, the Q 
element is supposed to insert quote marks.  Has anyone out there actually encountered a 
browser that handles that correctly?  (Part of my site's content is fiction, and I was 
thinking about using Q with the TITLE attribute to identify the speakers in a few chunks 
of dialogue.  Yet, when I tested it on IE5, no quotes.  Am I misreading the spec, or is 
IE5 noncompliant on this element?)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


*---------------------------------------------------------*
       E-Mail Delivery By VEI Internet Mail Services
   http://www.veiinternet.com - $14.95 Unlimited Internet

       Visit The New VEI Stores Open For Christmas:
       VEI DVD Store - http://vei.vstoredvds.com/
       VEI Book Store - http://veibooks.vstorebooks.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From antons at epos.co.za  Fri Nov  5 14:04:54 1999
From: antons at epos.co.za (Anton Schoultz - ePOS)
Date: Mon Jun  7 17:16:36 2004
Subject: oracle.xml.parser.v2.XSLProcessor & XSLStylesheet
Message-ID: <NBBBLIPEHIMMNAPFNOLCKELBEBAA.antons@epos.co.za>

Hi Gang,

Do any of you have experience in using oracle's parser stuff, in particular
the XSL Processor?

According to the very skimpy notes (see below) , the XSLStylesheet has a
constructor which takes two URL objects, one for the xsl, the other a
'Reference'.

I have set up an xml document, it's DTD and an xsl style sheet. I can browse
the xml with IE5 and it reads the style sheet and applies it as desired. Now
I want to do the stylesheet processing from inside a JAVA servlet. Thus far
the servlet can read and parse the XML using the DTD. But I can't seem to
get the code to build up the style sheet which I need as a parameter for the
XSL Processing.

Can anyone help ?

Regards
Anton


<quote>

 public XSLStylesheet(URL xsl,
                      URL ref) throws XSLException

Constructs an XSLStylesheet using the given URL

Parameters:
xsl - XSL input as a URL
ref - Reference URL for include, import and external entities
Throws: XSLException
on error.

</quote>


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



From smuench at us.oracle.com  Fri Nov  5 15:05:37 1999
From: smuench at us.oracle.com (Steve Muench)
Date: Mon Jun  7 17:16:36 2004
Subject: oracle.xml.parser.v2.XSLProcessor & XSLStylesheet
References: <NBBBLIPEHIMMNAPFNOLCKELBEBAA.antons@epos.co.za>
Message-ID: <008f01bf278e$77b2f780$01010101@us.oracle.com>

The 2nd argument is a URL which is used
as the base url for <xsl:import> and
<xsl:include>.

It's most relevant if you are passing
the XSLStylesheet() constructor an
InputStream as the first argument,
and it gives the class that extra bit
of "base uri" information that it
cannot get out of the stream.

If you're not using include/import,
then it's ok to pass a null.

So you can do:

// Create the Stylesheet from the stream
XSLStylesheet theXSLStylesheet = new XSLStylesheet(XSLStream,null);

// Create an instance of XSLProcessor to perform the transformation
XSLProcessor  processor = new XSLProcessor();

// Transform theXMLDoc by theXSLStylesheet and write result to
// System.out. This obeys all the rules of <xsl:output> while
// writing it out
processor.processXSL(theXSLStylesheet, theXMLDoc, System.out );

or

// Transform and keep hold of raw result DocumentFragment
DocumentFragment df = processor.processXSL(theXSLStylesheet, theXMLDoc);

You might want to check out the Oracle XSQL Servlet
on our Technet website which is a servlet that
does this for you already, as well as our XML Forum
on OTN where there's a Q and A forum on our components.

_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: Anton Schoultz - ePOS <antons@epos.co.za>
To: XML-DEV LIST <xml-dev@ic.ac.uk>
Sent: Friday, November 05, 1999 8:03 AM
Subject: oracle.xml.parser.v2.XSLProcessor & XSLStylesheet


| Hi Gang,
|
| Do any of you have experience in using oracle's parser stuff, in
particular
| the XSL Processor?
|
| According to the very skimpy notes (see below) , the XSLStylesheet has a
| constructor which takes two URL objects, one for the xsl, the other a
| 'Reference'.
|
| I have set up an xml document, it's DTD and an xsl style sheet. I can
browse
| the xml with IE5 and it reads the style sheet and applies it as desired.
Now
| I want to do the stylesheet processing from inside a JAVA servlet. Thus
far
| the servlet can read and parse the XML using the DTD. But I can't seem to
| get the code to build up the style sheet which I need as a parameter for
the
| XSL Processing.
|
| Can anyone help ?
|
| Regards
| Anton
|
|
| <quote>
|
|  public XSLStylesheet(URL xsl,
|                       URL ref) throws XSLException
|
| Constructs an XSLStylesheet using the given URL
|
| Parameters:
| xsl - XSL input as a URL
| ref - Reference URL for include, import and external entities
| Throws: XSLException
| on error.
|
| </quote>
|
|
| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
| Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
| To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
| unsubscribe xml-dev
| To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sguthery at rcn.com  Fri Nov  5 15:35:55 1999
From: sguthery at rcn.com (Scott Guthery)
Date: Mon Jun  7 17:16:37 2004
Subject: XML Scripting Language
References: <02f501bf274d$697fee20$0f044ccb@kit.redsquare.com.au>
Message-ID: <070401bf2807$e433b7e0$6e7d06d1@aa.net>

1) Is there a canonical scripting language for XML?  If
so, does it have a virtual machine and a bytecode set?

2) Has anbody compiled JavaScript or ECMAScript to the
WMLScript virtual machine bytecode set?  How about
Java, C or Visual Basic? COBOL? Fortran? Snobol?

Cheers, Scott

******************* Smart Card Developer's Kit *******************
Scott Guthery                                     sguthery@rcn.com
Voice: 617 964 1798    Mobile: 617 290 3963      FAX: 617 795 1630
*********************** http://www.scdk.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rgl at decisionsoft.com  Fri Nov  5 15:59:09 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:16:37 2004
Subject: XML Scripting Language
In-Reply-To: <070401bf2807$e433b7e0$6e7d06d1@aa.net>
Message-ID: <Pine.LNX.4.10.9911051551520.7062-100000@localhost.localdomain>

On Fri, 5 Nov 1999, Scott Guthery wrote:

> 1) Is there a canonical scripting language for XML?

If by canonical you mean "supported by a standards body" then the closest
thing to that is the W3C's XSL, which is still a Working Draft but is
derived from stylesheet languages that are recommended. However, while I'd
admit to being biased, I think the world of XML scripting is still
sufficiently in flux that it's sensible to choose a language on merit
rather than standards-body recommendation. Given the choice, I'd much
rather program in XML Script or Perl (with XML parser) than XSL.

> If
> so, does it have a virtual machine and a bytecode set?

I'm not aware of any that do.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov  5 16:11:21 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:16:37 2004
Subject: xll
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F27809A@MDYNYCMSX1>

>could anyone point me to some good resources regarding xll
>  is it being supported by IE5
>  thanx

IE has no direct support of XLink that I know of yet. See
http://www.xmlinfo.com/xll/ for good starting points on more information. 

Bob DuCharme       www.snee.com/bob       <bob@  
snee.com>  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dwshin at nlm.nih.gov  Fri Nov  5 17:31:35 1999
From: dwshin at nlm.nih.gov (Dongwook Shin)
Date: Mon Jun  7 17:16:37 2004
Subject: XRS (XML Retrieval System) update
Message-ID: <3823109D.E264AB01@nlm.nih.gov>

Hellow folks.

I just corrected an error that was included in the previous
downloadable version.
I was in a hurry to complete it just prior to going to a conference.
I was back this morning and found the error.

Please download again at the site :
http://dlb2.nlm.nih.gov/~dwshin/xrs.html

If you do not want to install the whole one,
you can only replace the "/retrieve/libretrieve.so" by the new one.
The former one was not able to show the XML content correctly.

I am sorry for the inconvenience.
Thanks.

Dongwook
--
Dongwook Shin
Visiting Scholar
Lister Hill National Center for Biomedical Communications
National Library of Medicine,
8600 Rockville Pike Bethesda 20894, MD
E-mail: dwshin@nlm.nih.gov
Tel: (301) 435-3257
FAX: (301) 480-3035
URL: http://dlb2.nlm.nih.gov/~dwshin



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



From lauren at sqwest.bc.ca  Fri Nov  5 18:02:35 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:16:37 2004
Subject: XML Scripting Language
In-Reply-To: <070401bf2807$e433b7e0$6e7d06d1@aa.net>
Message-ID: <199911051759.JAA23825@mail.sqwest.bc.ca>

On 5 Nov 99, at 22:34, Scott Guthery wrote:

> 1) Is there a canonical scripting language for XML?  If
> so, does it have a virtual machine and a bytecode set?

I don't know of a canonical scripting language for XML, but the 
Document Object Model (DOM) is a widely-implemented language-
neutral interface for XML. The specification includes ECMAScript 
and Java bindings, but there are several implementations in other 
languages as well (see 
http://dmoz.org/Computers/Programming/Internet/W3C_DOM/
for some of these). See http://www.w3.org/DOM for some more 
information.

cheers,

Lauren

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 18:13:26 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:37 2004
Subject: XHTML 1.0 returned to HTML WG
References: <003901bf271e$fe5a5be0$099918d1@docuverse1>
Message-ID: <3822FC81.D077B6F7@prescod.net>

Don Park wrote:
> 
> ><html:table><html:title/></html:table>
> >
> >And thanks to the one line spec, this is now legal. What the
> 
> There is an arguable common sense when we refer to a document as
> 'HTMLish' and I believe your example violates that. 

I don't think really need to argue the inappropriateness of the
juxtaposition of the phrase "common sense" and the acronym "HTML." 

10 years ago, HTML didn't have a DTD and it became popular to add
features to it just by announcing them to a mailing list. Once money
became involved, software vendors abused this precedent to invent their
own proprietary variants. Then everybody and their brother got into the
act. 

Now *I thought* we were supposed to be cleaning up the mess caused by
that unfortunate start...not duplicating it.

> If people are
> going to abuse namespace like that, it is our job to knock some
> sense into them rather than wrap them up in diapers and ducktape
> everything with foams. 

I don't really see how having formal, implementable specifications falls
into the diaper and ducktape category. Does XML wrap us up in ducktape?
SAX? DOM? HTML 4.0? Perhaps three years ago we should have released a
one line specification: "SGML may now be used on the Web. DOCTYPE
declarations are now optional. Otherwise, use your common sense."

--

Given: The XHTML namespace is only useful if we can write generic
software to work with it.

Given: We can only write generic software to work with it if we know how
the vocabulary is going to be used.

There must, therefore, be either explicitly or implicitly, an agreed
upon grammar for the vocabulary.

Why wouldn't we make that grammar explicit so that we could rely on our
understanding of the specification instead of our "common sense" both in
writing our own software and in holding vendors to the terms of our
"agreement?"

Although I will, admit on occasion to being a purist, in this case it
seems to me that what I am advocating is common sense. The whole point
of an HTML namespace is to increase interoperability right? Do you
really think that that's going to happen through the judicious
application of common sense and vendor-directed violence?

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 18:13:26 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:37 2004
Subject: "Multiple" Namespaces? (but NOT for HTML)
References: <Pine.GSO.4.05.9910281722300.4337-100000@jet.cc.emory.edu>
Message-ID: <3822FEFD.B399D565@prescod.net>

John Robert Gardner wrote:
> 
> <GoalScenario>
> Heinrich at Humboldt U. in Berlin is dilligently searching the world's
> various library resources with his Dublin-Core-Based engine for
> <Creator>Tillich</Creator> and we want his DC system to transparently find
> the wealth of Tillich articles we'd have online.
> </GoalScenario>

Let's say that in five years we come up with a new peer to DC, TEI or
GILS. Let's say we call it "newmeta" We may need to make this new system
compatible with our existing data. We probably do not have the luxury of
re-encoding all of the data. So our problem is to make the existing data
"look as if" it is compatible with newmeta. I think that we should start
with that as a design goal. We need to be able to make the data look as
if it supports multiple schemes *without requiring the markup to support
all of those schemes*.

The next question is how varied the queries will be. Is straight
name-value indexing sufficient? Or do you need to allow XPath queries on
the "DC version", "TEI version", "GILs version" and so forth? Is XPath a
good query language for metadata to start with? Maybe the right place to
put your abstraction is in the metadata data model. It's my duty to
point out that you should evaluate RDF in that capacity though I don't
claim to be an RDF expert myself.

XML's data model is elements within elements. RDF's data model is
structured properties with values. It seems like a better fit but I
don't know of an RDF query language -- I don't know what people use for
querying RDF.

> >  * It increases the possibility for error: authors or data generators
> > could "forget" to insert a TEI:docAuthor alongside a DC:Creator.
> 
> Yes and no, since most of our input is one-time only, rather than
> respeatedly updated or nuanced.  THe finished article and record entry is
> a one-time keying (or XSLT transformed) deal.

Even if it is a one-time keying, if you quadruple the number of tags,
you'll increase the number of typos.

> 1. as it is an SGML subset standard, our "standards" caveat is ostensibly
> met, but-- per the <snip> above-- it seems not necessarily "happy" with
> XML -- or I'm misreading you?  At any rate as ISO 10744:1997, AAnnex A.3
> it seems very viable . .. . except-- cf. caveats 2 and 3 below:

Yes, architectural forms work fine with XML now. But to some degree you
must choose your solution based on the software available. There are
various toolkits that are archform aware but I don't know of any
repositories or search engines that index based on archforms.

> 2.  Will Arch forms work with our Oracle investment to date (we're
> considering SIM and related technology for our next Phase)?

Archforms are the manner of representing your aliasing. Oracle has a
variety of ways to support aliasing but it won't read archforms
directly. You would have to write code to implement the aliasing.

> Will this mechanism achieve the transparency for our users in diaspora
> referred to above--and hopefully I made better sense this time--in the
> <GoalScenario> section? Because we discussed using attributes for teh
> different synonymous--or largely so-- tags like
> docAuthor/Creator/Originator, etc., but we were under the impression that,
> per below as well, attributes wouldn't achieve our implementation of
> transparent accessibility.

An architectural form engine implicitly transforms the data.

So you type:

<emory:author>Paul</emory:author>

And then a batch architectural form processor could convert it into:

<DC:Creator>Paul</DC:Creator>

A mythical architectural form-smart search engine would "pretend" to do
that conversion, in real-time, when the query was done and cache the
results intelligently. But such a thing doesn't exist as a general tool.

> The obvious bottom line is the transparency, in the end, the software
> required, legacy investment or none-- is secondary to this requirement,
> given that we are implementing an open/int'l standard.  

I think that one thing we still have to hash out is the natural data
model for querying this information. 

If it is flat text name-value pairs, Oracle will be great and the
problem will be trivial to solve. Simple name aliasing is all you need.

It is is structured property name-value pairs then you need something
object orientish like an RDF engine or an object database. You need name
aliasing but it needs to be hierarchical.

If the proper model is elements within elements then you need an
XML-specific solution like architectural forms. That's going to be
harder to find.

> Put our initial stash of MARC records, via my XSLT work and such, into
> --say-- Dublin Core for the Oracle database to store, and then construct
> an XML document which is a tagbag of empty elements with attributes which
> equivocate that the Dublin Core Creator is the same as TEI docAuthor, etc.
> This sounds like Arch. Forms, in a way, but--as noted--I'm not convinced I
> fully grok arch forms anyway.

It sounds like you are proposing an alternate representation for the
same thing that architectural forms allows. I think that the
representation is a lesser problem than finding the software that wlil
allow your queries to scale and be extensible.

> This is also not unlike what we're considering, but it sounds from your
> post like it enables folks to come to your search engine and do these
> multiple search types via the common mapping you've set up, wherein, per
> the <GoalScenario> above, we want folks to be able to do this with their
> existing native search system.

What exactly do you mean by that? The data exists in one place, right?
Or are you distributing the XML files around the world? If it exists in
one place, then what software looks at the information? Surely
researchers around the world cannot all be banging on the same files at
the same time. That's why we typically use server software.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 19:26:24 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:37 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: Paul Prescod's message of "Fri, 05 Nov 1999 09:49:21 -0600"
References: <003901bf271e$fe5a5be0$099918d1@docuverse1> <3822FC81.D077B6F7@prescod.net>
Message-ID: <m3iu3givwn.fsf@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> I don't really see how having formal, implementable specifications falls
> into the diaper and ducktape category. Does XML wrap us up in ducktape?
> SAX? DOM? HTML 4.0? Perhaps three years ago we should have released a
> one line specification: "SGML may now be used on the Web. DOCTYPE
> declarations are now optional. Otherwise, use your common sense."

Well, I would have made it a couple paragraphs longer, but in essence, 
that might have served, except for two problems:

1. The SGML spec is not freely available.

2. XML removes so many details from SGML that it makes more sense to
   distribute it as a separate spec than as a set of deltas. 


All the best,


David

p.s. Shouldn't that be "duct tape", Paul and Don?  We don't want the
     SPCA down on us.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 19:58:34 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:37 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <3822FC81.D077B6F7@prescod.net>
Message-ID: <000101bf27c8$60308c00$099918d1@docuverse1>

Paul Prescod wrote:

>Given: The XHTML namespace is only useful if we can write generic
>software to work with it.
>
>Given: We can only write generic software to work with it if 
>we know how
>the vocabulary is going to be used.
>
>There must, therefore, be either explicitly or implicitly, an agreed
>upon grammar for the vocabulary.

I agree with you entirely.  What we disgree on whether the spec should
be broken up into two for sake of expediency.  The three line spec
in question simply assigns a namespace for HTML and settles the
case-sensitivity issue.  We can use that three line spec now to move
forward while the grammar spec is being worked on.  Until the grammar
spec is finished, we have only common sense to guide us when designing
HTMLish XML documents.

I think everyone will agree that one can't create a new spoken language
using French words and still call it French.  That is what I mean by
common sense.

>Although I will, admit on occasion to being a purist, in this case it
>seems to me that what I am advocating is common sense. The whole point
>of an HTML namespace is to increase interoperability right? Do you
>really think that that's going to happen through the judicious
>application of common sense and vendor-directed violence?

More like peer-directed violence.  All the boys learn to say
"Girls! Yuck!" from watching other boys.  I don't think there will be
much vendor-directed violence nor abuse of common sense now when there
are active groups like XML-DEV waiting to jump in and scream, "You made
a Boo-Boo!"  <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Curt.Arnold at hyprotech.com  Fri Nov  5 20:15:57 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:16:37 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <61DAD58E8F4ED211AC8400A0C9B46873415488@THOR>

Duck ? Tape is a registered trademark of Manco, Inc.
http://www.manco.com/duck/ip.htm
I don't know if they licensed its use for 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jes at kuantech.com  Fri Nov  5 20:27:46 1999
From: jes at kuantech.com (Jeffrey E. Sussna)
Date: Mon Jun  7 17:16:37 2004
Subject: WML vs. XHTML
In-Reply-To: <02f501bf274d$697fee20$0f044ccb@kit.redsquare.com.au>
Message-ID: <000001bf27cb$6ad854f0$0f36a8c0@quokka.com>

Any language that contains a construct called "GOSUB" deserves dustbin
status. :-)

Jeff Sussna

> -----Original Message-----
> [ snip ]
>
>    <ACTION TYPE=ACCEPT TASK=GOSUB VARS=host=$(hostname)
>
> [ snip ]
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 20:31:57 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:37 2004
Subject: XHTML 1.0 returned to HTML WG
In-Reply-To: <m3iu3givwn.fsf@localhost.localdomain>
Message-ID: <000401bf27cc$fa4e2460$099918d1@docuverse1>

>p.s. Shouldn't that be "duct tape", Paul and Don?  We don't want the
>     SPCA down on us.

Hmm.  What do they use in Canada for putting their ducks in a row?
I don't know about you but ducks tend to move around a lot so I have
to use the 'duck-tape' to tape them in-place. <g>

"Quack!"

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Patrice.Bonhomme at loria.fr  Fri Nov  5 20:37:46 1999
From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme)
Date: Mon Jun  7 17:16:37 2004
Subject: A unique ID question ?
Message-ID: <199911052037.VAA02691@chimay.loria.fr>


Hi,

I was wondering if the value of an ID attribute has to be unique within a 
document or only within a fragment. The pb is that i have a master document 
that contains some external system entities and each of the entity is a 
fragment that contains some ID attributes. If my processor includes all the 
fragments it may happen that some ID attributes have the same value.

What do i have to do ? Provide an IDentificstion schema that should avoid ID 
value clash or rename each of the attribute when i include each fragment to 
avoid the clash (with a prefix for example) ?



Pat.

-- 
  ==============================================================
   bonhomme@loria.fr      Tel : 03 83 59 30 52 / 06 11 34 03 85
   http://www.loria.fr/~bonhomme                 Office : B.228
  --------------------------------------------------------------
   * Serveur Silfide  : http://www.loria.fr/projets/Silfide
  ==============================================================



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



From hpang at flycast.com  Fri Nov  5 21:00:56 1999
From: hpang at flycast.com (Hokkun Pang)
Date: Mon Jun  7 17:16:37 2004
Subject: getting element value in DOM
Message-ID: <A7C924760A6BD311B97E0090271EB91047EA55@post.flycast.com>

I have read the DOM level 1 a couple times but I simply don't
see the API for accessing the entity value.
Suppose I am parsing this:

	<email>abc@yahoo.com</email>

which API should I use to get the 'abc@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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Simon.Gordon at swi.galileo.com  Fri Nov  5 21:18:43 1999
From: Simon.Gordon at swi.galileo.com (Gordon, Simon)
Date: Mon Jun  7 17:16:37 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <BB8185A675F3D211890D000024C8B8D284711A@denexc02.galileo.com>

> Don Park 
> 
> >p.s. Shouldn't that be "duct tape", Paul and Don?  We don't want the
> >     SPCA down on us.
> 
> Hmm.  What do they use in Canada for putting their ducks in a row?
> I don't know about you but ducks tend to move around a lot so I have
> to use the 'duck-tape' to tape them in-place. <g>
> 
> "Quack!"
> 

Orange Sauce. I'm (un)reliably informed.

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



From jelks at jelks.nu  Fri Nov  5 22:24:21 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:37 2004
Subject: WML vs. XHTML
In-Reply-To: <0.c4b12b3d.2553d3b5@aol.com>
Message-ID: <NBBBICMNIPCICMKJECCBMECNDBAA.jelks@jelks.nu>

XMLDevGuy wrote:

> WML is a more advanced than HDML as it includes WMLScripting (for storing
> variables across multiple cards and access to special phone features),
> following the DTD for WML pretty much gives you everything that one needs to
> know for creating a Deck.  A Deck is also an XML Doc.
>
> Being an avid DHTML developer, is XHTML worth looking @ at this point?

Comparing [x]HTML to WML -- 5 years down the road when phones are using real web
browsers that can hit pages written for *everybody*, where do you think WML is
going to be left standing?  [x]HTML obviously has a future.  I'd be cautious
about spending much time with WML unless you absolutely *have* to author for
these current-generartion crippled 9.6Kbps (GSM) and 14.4Kbps (CDMA) devices.
I've played around with the "Wireless Web" on one of the new SprintPCS dual-band
Touchpoints, but I found it extremely painful -- and you can only read the
"special" WML or HDML pages.

You really ought to check out http://www.4k-associates.com/IEEE-L7-WAP-BIG.html


From jelks at jelks.nu  Fri Nov  5 22:36:39 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
In-Reply-To: <000001bf27cb$6ad854f0$0f36a8c0@quokka.com>
Message-ID: <NBBBICMNIPCICMKJECCBEECODBAA.jelks@jelks.nu>

Jeffrey E. Sussna wrote:

> >    <ACTION TYPE=ACCEPT TASK=GOSUB VARS=host=$(hostname)

> Any language that contains a construct called "GOSUB" deserves dustbin
> status. :-)

Indeed. Check out this little snip from Rohit Khare's "W* Effect Considered
Harmful":

	One way to think of WML is as programming 3270 screens
	with a very simple BASIC. An application is delivered to
	the handset as a 'deck', which allocates a corresponding
	pool of storage space for variables. Individual 'cards'
	are executed on entry and exit to render the handset
	screen: they can fill in (shared) variables, rerender on
	external event notifications (e.g. call completed), and
	bind further actions to a small set of buttons. The
	display calls themselves are essentially character-cell
	oriented, with tab alignment and bold, italic,
	underline, big, and small fonts. Tables, frames, colors,
	and so on are not supported. Semantic HTML markup like
	<ADDRESS> must be stripped out. Even simple declarative
	HTML doesn't mean what it used to -- <P> no longer
	begins a new line. 'Graphics' support is intended mainly
	for optional icons in place of text menus; no clickable
	menu maps or such.  WML is really a scripting language...

That's just the tip of the iceberg -- check out how they've "reinvented" TCP/IP:

	http://www.4k-associates.com/IEEE-L7-WAP-BIG.html


/Jelks


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 22:40:01 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:38 2004
Subject: XHTML 1.0 returned to HTML WG
References: <000101bf27c8$60308c00$099918d1@docuverse1>
Message-ID: <382327B2.A091F84E@prescod.net>

Don Park wrote:
> 
> I agree with you entirely.  What we disgree on whether the spec should
> be broken up into two for sake of expediency.  The three line spec
> in question simply assigns a namespace for HTML and settles the
> case-sensitivity issue.  

To what end? With no specification for how to mix HTML into other
namespaces there will be no interoperability. Without interoperability
what's the point of a spec?

> We can use that three line spec now to move
> forward while the grammar spec is being worked on.  

Move forward how? People have been mixing HTML elements into other
doctypes for at least five years now. We've achieved little economy of
scale in doing that because recognizing a paragraph with some
proprietary junk mixed in, in the middle of a proprietary document type
is not that useful. That's why I don't understand Tim and David's
excitement about the "power" of mixing HTML into things. Mixing HTML
into things is not rocket science. Doing sophisticated things in a
generic way, with generic software, with mixed in HTML IS rocket
science. But it requires a real spec for mixable HTML, not a paragraph.

> Until the grammar
> spec is finished, we have only common sense to guide us when designing
> HTMLish XML documents.

The same common sense we've had for many years. The same HTMLish
non-HTML documents we've had for many years. What does a namespace
change? It just allows us to pretend we've got interoperability when we
do not.

> More like peer-directed violence.  All the boys learn to say
> "Girls! Yuck!" from watching other boys.  I don't think there will be
> much vendor-directed violence nor abuse of common sense now when there
> are active groups like XML-DEV waiting to jump in and scream, "You made
> a Boo-Boo!"  <g>

Who's to say its a boo boo if there's no spec? Titles in the middle of a
document might make perfect sense in meta-X-HTML. Tables in meta-X-HTML
might have <title>s.

That's just the point: we can't apply sociological pressure without a
constitution to refer to. We can hardly say: "That's different than
HTML" because the whole point of the namespace is to allow HTML element
types to be used in not-HTML.

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  5 22:41:10 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:38 2004
Subject: XHTML 1.0 returned to HTML WG
References: <000101bf27c8$60308c00$099918d1@docuverse1>
Message-ID: <382327C6.51375A8A@prescod.net>

Don Park wrote:
> 
> I agree with you entirely.  What we disgree on whether the spec should
> be broken up into two for sake of expediency.  The three line spec
> in question simply assigns a namespace for HTML and settles the
> case-sensitivity issue.  

To what end? With no specification for how to mix HTML into other
namespaces there will be no interoperability. Without interoperability
what's the point of a spec?

> We can use that three line spec now to move
> forward while the grammar spec is being worked on.  

Move forward how? People have been mixing HTML elements into other
doctypes for at least five years now. We've achieved little economy of
scale in doing that because recognizing a paragraph with some
proprietary junk mixed in, in the middle of a proprietary document type
is not that useful. That's why I don't understand Tim and David's
excitement about the "power" of mixing HTML into things. Mixing HTML
into things is not rocket science. Doing sophisticated things in a
generic way, with generic software, with mixed in HTML IS rocket
science. But it requires a real spec for mixable HTML, not a paragraph.

> Until the grammar
> spec is finished, we have only common sense to guide us when designing
> HTMLish XML documents.

The same common sense we've had for many years. The same HTMLish
non-HTML documents we've had for many years. What does a namespace
change? It just allows us to pretend we've got interoperability when we
do not.

> More like peer-directed violence.  All the boys learn to say
> "Girls! Yuck!" from watching other boys.  I don't think there will be
> much vendor-directed violence nor abuse of common sense now when there
> are active groups like XML-DEV waiting to jump in and scream, "You made
> a Boo-Boo!"  <g>

Who's to say its a boo boo if there's no spec? Titles in the middle of a
document might make perfect sense in meta-X-HTML. Tables in meta-X-HTML
might have <title>s.

That's just the point: we can't apply sociological pressure without a
constitution to refer to. We can hardly say: "That's different than
HTML" because the whole point of the namespace is to allow HTML element
types to be used in not-HTML.

Let me ask you another question about your two-stage plan. So in version
1 we deploy hundred of HTML-ish documents using the same case
conventions (!) and namespace but totally open content models. Then
later we deploy the grammar. What do we do about the installed base of
grammar non-conformant data? Doesn't this sound familiar???

 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov  5 22:50:54 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:16:38 2004
Subject: A unique ID question ?
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F2780A6@MDYNYCMSX1>

>I was wondering if the value of an ID attribute has to be unique within a 
>document or only within a fragment.

>From the "ID" validity constraint in section 3.3.1 of the spec
(http://www.w3.org/TR/REC-xml#sec-attribute-types): "A name must not appear
more than once in an XML document as a value of this type; i.e., ID values
must uniquely identify the elements which bear them."

Bob DuCharme       www.snee.com/bob       <bob@  
snee.com>  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov  6 00:38:22 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:16:38 2004
Subject: getting element value in DOM
In-Reply-To: <A7C924760A6BD311B97E0090271EB91047EA55@post.flycast.com>
Message-ID: <Pine.GSU.4.10.9911051633110.29954-100000@netcom9.netcom.com>

On Fri, 5 Nov 1999, Hokkun Pang wrote:

> I have read the DOM level 1 a couple times but I simply don't
> see the API for accessing the entity value.
> Suppose I am parsing this:
> 
> 	<email>abc@yahoo.com</email>
> 
> which API should I use to get the 'abc@yahoo.com'?

"abc@yahoo.com" is the value ('data' property) of a Text node which is the
first child of the Element node whose tagName is 'email'), so assuming
that MyElement is the Element node, you'd access the value (FSVO language
binding) as MyElement.firstChild.data.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  6 03:45:15 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
References: <NBBBICMNIPCICMKJECCBEECODBAA.jelks@jelks.nu>
Message-ID: <3823A36E.1E15@hiwaay.net>

Jelks Cabaniss wrote:
> 
> Jeffrey E. Sussna wrote:
> 
> > >    <ACTION TYPE=ACCEPT TASK=GOSUB VARS=host=$(hostname)
> 
> > Any language that contains a construct called "GOSUB" deserves dustbin
> > status. :-)

<a href= : the great leveler, the chosen symbol, the getItBox.

> Indeed. Check out this little snip from Rohit Khare's "W* Effect Considered
> Harmful":

So: in geek

> 
>         One way to think of WML is as programming 3270 screens
>         with a very simple BASIC. 

frame  

>         An application is delivered to
>         the handset as a 'deck', the deck is 

named fragments

>         which allocates a corresponding
>         pool of storage space for variables. 

so that a namespace names

>         Individual 'cards'
>         are executed on entry and exit

and formats

>         to render the handset
>         screen: 

and binds namespaces

>        they can fill in (shared) variables, 

dynamically


>         rerender on
>         external event notifications (e.g. call completed), and

names bound to controls

 >        bind further actions to a small set of buttons. 

format geometry for interaction, morphs, multiD, aggregate sets

>         The
>         display calls themselves are essentially character-cell
>         oriented, with tab alignment and bold, italic,
>         underline, big, and small fonts. Tables, frames, colors,
>         and so on are not supported. 

binds format.  go3D.  kids hate buttons. give them personalities 
and adventure.  the world is not small nor is the reach of our 
tools to communicate and be human together.  make it more 
exciting than windows and win.

>         Semantic HTML markup like
>         <ADDRESS> must be stripped out. Even simple declarative
>         HTML doesn't mean what it used to -- <P> no longer
>         begins a new line. 'Graphics' support is intended mainly
>         for optional icons in place of text menus; no clickable
>         menu maps or such.  WML is really a scripting language...

which is what you need for prebinding information to occasionally
connected devices.

The nice thing about lowlyFrame design:  the initial allocation of IDs
is clean if the 
trees name attribute sets.  One id to fetch a subtree.

Give up some semantics in that instance to get more certain binding of
control to value by device.
The next instance is yours to transform as you will.  Accumulate
namespaces temporally.
Schemas must be temporally adaptive.  That is why XML schema.  That is
why namespaces.

We do it anyway.  How many messages are used in this system which are
NOT 
timestamped?  Can we make schema more adaptive by finding principles for
applying 
that timestamping more efficiently?  Types aggregate in time. 
TreeClusters 
of named events and types are bound such that when it changes in one
part of the 
tree, it changes in all the others at the same time.  A variable is
forced to 
be polite because it is unique so it changes at the same time in any of
the 
dimensions in which it is represented.

> That's just the tip of the iceberg -- check out how they've "reinvented" TCP/IP:

For the protocol gypsies to say.  Pre-aggregating trees is a way to make
the pgs work less.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  6 03:45:08 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
References: <000001bf27cb$6ad854f0$0f36a8c0@quokka.com>
Message-ID: <38237DAB.99A@hiwaay.net>

Jeffrey E. Sussna wrote:
> 
> Any language that contains a construct called "GOSUB" deserves dustbin
> status. :-)

Such as

<a href=

:-)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From XMLDevGuy at aol.com  Sat Nov  6 05:05:53 1999
From: XMLDevGuy at aol.com (XMLDevGuy@aol.com)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
Message-ID: <0.14438d10.255510ff@aol.com>

In a message dated 11/5/99 10:32:23 PM !!!First Boot!!!, jelks@jelks.nu 
writes:

<< Comparing [x]HTML to WML -- 5 years down the road when phones are using 
real web
 browsers that can hit pages written for *everybody*, where do you think WML 
is
 going to be left standing?  [x]HTML obviously has a future.  I'd be cautious
 about spending much time with WML unless you absolutely *have* to author for
 these current-generartion crippled 9.6Kbps (GSM) and 14.4Kbps (CDMA) devices.
 I've played around with the "Wireless Web" on one of the new SprintPCS 
dual-band
 Touchpoints, but I found it extremely painful -- and you can only read the
 "special" WML or HDML pages >>

Well one of my last jobs was built using XML -> WML only because it was the 
only solution in that the parties didn't want to throw in alot more money for 
Palm devices, a case study here:

http://www.digitalanywhere.com/casestudy1.html

Thanks for that link, it was a very good insight!  There was alot to be 
pointed out notably that WMLScripting is VERY platform dependent on what 
device you are using.  For example there are no calls to:

device://AddressBook?type=add&name=...

If this were the case with any language then it would make Palm programming 
and other device programming alot more simpler, wouldn't one think?  Thank 
god for something like the W3C or else there would be ALOT more of a mess out 
there when it comes to wireless connected devices.  

It still seems though as if WAP is off and running...

- Jon


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



From AlanM at SYNECTICS.Soft.net  Sat Nov  6 06:25:17 1999
From: AlanM at SYNECTICS.Soft.net (Alan Menezes)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
Message-ID: <1F4436D26763D2119B8800A0C9DE68979A9EF3@MAIL>


> Hi all.
> Since we are talking about WML.
> Are there WAP enabled Handsets(for mobile phones) available?
> Do we need to use the WAP gateway to render on to a mobile phone?
> What about UIML? Can UIML be used to render onto the mobile phones?
> thanks and regards,
> Alan

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



From ian at imolesworth.demon.co.uk  Sat Nov  6 11:52:06 1999
From: ian at imolesworth.demon.co.uk (Ian Molesworth)
Date: Mon Jun  7 17:16:38 2004
Subject: Schema content tools
Message-ID: <002501bf284d$48fd0ec0$86e1dec2@demon.co.uk>

Ok,

Is there a schema generation tool, team based, that I can use to generate and control tags and elements during the build of my XML based system?

What I want is a tool that uses a central repository to store the current tag schema, allowing me control over authoring of new subsets of tags by issuing different developers access to variouus sections of the schema. General developers need read-only access to the current schema to verify their use of tags, source of data etc.

Any ideas?

Ian 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991106/2a0c042a/attachment.htm
From rgl at decisionsoft.com  Sat Nov  6 13:42:39 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
In-Reply-To: <1F4436D26763D2119B8800A0C9DE68979A9EF3@MAIL>
Message-ID: <Pine.LNX.4.10.9911061339420.10475-100000@tugela.dsl.net>

On Sat, 6 Nov 1999, Alan Menezes wrote:

> > Hi all.
> > Since we are talking about WML.
> > Are there WAP enabled Handsets(for mobile phones) available?

There are hardly any around, but they do exist. The only one I've seen is
the Nokia 7110.

> > Do we need to use the WAP gateway to render on to a mobile phone?

To render onto a WAP phone, yes. Both Ericsson and Nokia have publicly
accessible (for test purposes) gateways - the IP address is buried
somewhere on their websites.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  6 15:20:11 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun  7 17:16:38 2004
Subject: WML vs. XHTML
In-Reply-To: <Pine.LNX.4.10.9911061339420.10475-100000@tugela.dsl.net>
References: <1F4436D26763D2119B8800A0C9DE68979A9EF3@MAIL>
Message-ID: <199911061519.KAA06469@earth.isni.net>

At 01:42 PM 11/6/99 +0000, Richard Lanyon wrote:
>On Sat, 6 Nov 1999, Alan Menezes wrote:
>
>> > Hi all.
>> > Since we are talking about WML.
>> > Are there WAP enabled Handsets(for mobile phones) available?
>
>There are hardly any around, but they do exist. The only one I've seen is
>the Nokia 7110.

They're becoming more and more available. 

I've got a Samsung 3500 with service provided by SprintPCS (produced by
phone.com). 

Ann
--
Ann Navarro
Author: Effective Web Design: Master the Essentials, 
Due 10/99 - Mastering XML,12/99 HTML By Example, 2nd Ed.

Founder, WebGeek Communications http://www.webgeek.com/
Director, Online Education-HTML Writers Guild, http://www.hwg.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov  6 17:52:11 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:16:39 2004
Subject: bibiography dtd?
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16F4D@martinique>

I'm in the process of xmlating (or is it xmlizing?) bibliographic data.  Is
there a standard in the house?  I need to be able to easily get stuff in and
out of standard formats like bibtex and procite.  At a minimum I'd like to
maintain author and publisher info separately and reference it from the
bibliographic entries.  Maybe also periodicals and collections.  Then use
XSLT to do cool stuff with it.  Really do not want to write the XSLT stuff
more than once.  Advice?

Gregg Reynolds


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



From jmcdonou at library.berkeley.edu  Sat Nov  6 20:18:43 1999
From: jmcdonou at library.berkeley.edu (Jerome McDonough)
Date: Mon Jun  7 17:16:39 2004
Subject: bibiography dtd?
In-Reply-To: <51ED3F5356D8D011A0B1006097C3073401B16F4D@martinique>
Message-ID: <199911062018.PAA03539@westnet.com>

At 11:54 AM 11/6/99 -0600, Reynolds, Gregg wrote:
>I'm in the process of xmlating (or is it xmlizing?) bibliographic data.  Is
>there a standard in the house?

Sort of, but it's really scary.  The official standard for interchange of
bibliographic
data within the U.S. is the USMARC standard.  There is an official SGML
version of it, developed by the Library of Congress, along with conversion
utiltities.
WARNING WILL ROBINSON: unless you've been to library school and paid
*close* attention in your cataloging class, about 33% of the DTD will be
incomprehensible on its face, and a lot of things you *think* you understand
don't mean what a rational person would assume they do.  Also, be forewarned 
that the two separate DTDs for the MARC stuff are rather large and
difficult to
digest.  
However, any organization that does any significant processing of
bibliographic

data (publishers and libraries) typically has systems in place for dealing
with
MARC 
records that get shipped to them.  If you use an SGML version of MARC for
your 
own stuff (or XML that conforms to the SGML DTD), you should be able to
translate 
into MARC for record interchange with other people using MARC-based systems.



Jerome McDonough -- jmcdonou@library.Berkeley.EDU  |  (......)
Library Systems Office, 386 Doe, U.C. Berkeley     |  \ *  * /
Berkeley, CA 94720-6000    (510) 642-5168          |  \  <>  /
"Well, it looks easy enough...."                   |   \ -- /  SGNORMPF!!!
         -- From the Famous Last Words file        |    ||||

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



From jelks at jelks.nu  Sun Nov  7 01:30:31 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:39 2004
Subject: WML vs. XHTML
In-Reply-To: <199911061519.KAA06469@earth.isni.net>
Message-ID: <NBBBICMNIPCICMKJECCBCEDHDBAA.jelks@jelks.nu>

Ann Navarro wrote:

> >> > Since we are talking about WML.
> >> > Are there WAP enabled Handsets(for mobile phones) available?
> >
> >There are hardly any around, but they do exist. The only one I've seen is
> >the Nokia 7110.
> 
> They're becoming more and more available. 
> 
> I've got a Samsung 3500 with service provided by SprintPCS (produced by
> phone.com). 

There's a list of WAP-enabled SprintPCS phones at:

	http://www.sprintpcs.com/wireless/capable_phones.html

Pretty much all the new (and upcoming) SPCS phones will have it.

Too bad they'll never read [x]HTML pages.  


/Jelks


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov  7 02:49:31 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:16:39 2004
Subject: A unique ID question ?
References: <199911052037.VAA02691@chimay.loria.fr>
Message-ID: <3824E917.78555C71@isogen.com>

This is why external parsed entities ("external text entities" in SGML
parlance) are evil and should never have been included in XML.

The only complete and managable solution to this problem is to manage
each component as a complete and independent document and combine them
together *semantically* using something like XLink or HyTime's value
reference facility (explicit use-by-reference as distinct from
hyperlinking).

Cheers,

E.

Patrice Bonhomme wrote:
> 
> Hi,
> 
> I was wondering if the value of an ID attribute has to be unique within a
> document or only within a fragment. The pb is that i have a master document
> that contains some external system entities and each of the entity is a
> fragment that contains some ID attributes. If my processor includes all the
> fragments it may happen that some ID attributes have the same value.
> 
> What do i have to do ? Provide an IDentificstion schema that should avoid ID
> value clash or rename each of the attribute when i include each fragment to
> avoid the clash (with a prefix for example) ?

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov  7 04:03:13 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun  7 17:16:39 2004
Subject: WML vs. XHTML
In-Reply-To: <NBBBICMNIPCICMKJECCBCEDHDBAA.jelks@jelks.nu>
References: <199911061519.KAA06469@earth.isni.net>
Message-ID: <199911070403.XAA25496@earth.isni.net>

At 08:30 PM 11/6/99 -0500, Jelks Cabaniss wrote:

>Too bad they'll never read [x]HTML pages.  


Never? Right now, the service provides select information proxied through a
customized service. SprintPCS hasn't yet enabled all that can be done with
these phones. This offering is brand new -- and is surely to expand as the
technology stabilizes. After all, at least in my Sprint market, the best we
had was text paging that could be generated "from" the Web, rather than
actual web browsing. 

That said, the producers of the Sprint mini-browser, phone.com, are on the
W3C HTML WG, and are very interested in providing broad access to Web
content, including XHTML.

Spent two days in Boston this past week (W3C AC meeting), and sat with one
of phone.com senior engineers. His phone (connecting through phone.com's
own service), was significantly more "enabled" than mine was -- in fact, he
received and we read Tim's message wrt: the disposition of XHTML on his
phone, as well as looked around at other information I couldn't yet get on
my phone. 

"Never" isn't a word that's very applicable in this situation. 

Ann


--
Ann Navarro
Author: Effective Web Design: Master the Essentials, 
Due 10/99 - Mastering XML,12/99 HTML By Example, 2nd Ed.

Founder, WebGeek Communications http://www.webgeek.com/
Director, Online Education-HTML Writers Guild, http://www.hwg.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sguthery at rcn.com  Sun Nov  7 05:00:16 1999
From: sguthery at rcn.com (Scott Guthery)
Date: Mon Jun  7 17:16:39 2004
Subject: WML vs. XHTML
References: <199911061519.KAA06469@earth.isni.net> <199911070403.XAA25496@earth.isni.net>
Message-ID: <001401bf2941$769bac70$6e7d06d1@aa.net>

At 7 cents per screen it seems to me that the WAP business model
is trying to be like the text paging business model which has had to 
say the least limited success.  The technology may be wonderful but 
if the value proposition fails then business fails.

******************* Smart Card Developer's Kit *******************
Scott Guthery                                     sguthery@rcn.com
Voice: 617 964 1798    Mobile: 617 290 3963      FAX: 617 795 1630
*********************** http://www.scdk.com **********************
----- Original Message ----- 
From: Ann Navarro <ann@webgeek.com>
To: Jelks Cabaniss <jelks@jelks.nu>; <xml-dev@ic.ac.uk>
Sent: Saturday, November 06, 1999 10:59 PM
Subject: RE: WML vs. XHTML


At 08:30 PM 11/6/99 -0500, Jelks Cabaniss wrote:

>Too bad they'll never read [x]HTML pages.  


Never? Right now, the service provides select information proxied through a
customized service. SprintPCS hasn't yet enabled all that can be done with
these phones. This offering is brand new -- and is surely to expand as the
technology stabilizes. After all, at least in my Sprint market, the best we
had was text paging that could be generated "from" the Web, rather than
actual web browsing. 

That said, the producers of the Sprint mini-browser, phone.com, are on the
W3C HTML WG, and are very interested in providing broad access to Web
content, including XHTML.

Spent two days in Boston this past week (W3C AC meeting), and sat with one
of phone.com senior engineers. His phone (connecting through phone.com's
own service), was significantly more "enabled" than mine was -- in fact, he
received and we read Tim's message wrt: the disposition of XHTML on his
phone, as well as looked around at other information I couldn't yet get on
my phone. 

"Never" isn't a word that's very applicable in this situation. 

Ann


--
Ann Navarro
Author: Effective Web Design: Master the Essentials, 
Due 10/99 - Mastering XML,12/99 HTML By Example, 2nd Ed.

Founder, WebGeek Communications http://www.webgeek.com/
Director, Online Education-HTML Writers Guild, http://www.hwg.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov  7 17:41:43 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:39 2004
Subject: A unique ID question ?
References: <199911052037.VAA02691@chimay.loria.fr> <3824E917.78555C71@isogen.com>
Message-ID: <3825B758.6A3A@hiwaay.net>

W. Eliot Kimber wrote:
> 
> This is why external parsed entities ("external text entities" in SGML
> parlance) are evil and should never have been included in XML.

Evil or inconvenient, we are stuck with them.  The same issues 
has come up in the DTD for X3D/VRML.  Well-formedness 
and namespaces don't exactly cohere as concepts in practice.

For that reason, there was a short consideration to declare them as
NMTOKEN.  
At least, they would weakly validate.  If we declare DEF/USE
combinations 
as ID/IDREF:

1. Cannot duplicate DEFs:  VRML97 allows this with undefined results.  
Essentially, in implementation, the last guy declared is used 
by the next guy.  Some authoring tools also flag an error for the author 
to clean up.

2.  Name collisions:  Inlines have to be scoped.  PROTOS and 
extenal PROTOS have to be scoped.  If one aggregates, one has 
to declare all of the scopes and validate them individually, 
or not use ID/IDREF.  It is probably better to support the 
semantics upstream of the broadcast products and keep the 
client thin as a fashion model.

> The only complete and managable solution to this problem is to manage
> each component as a complete and independent document and combine them
> together *semantically* using something like XLink or HyTime's value
> reference facility (explicit use-by-reference as distinct from
> hyperlinking).

Ensure that any translation or conversion tool uniquefies names 
where used as IDs.  

Whether done with Xlink or valuerefs, some means to explicitly 
spec name resolution is needed.  Given the time required to get 
changes through multiple language ecosystems, my intuition is 
this will be a problem for a long time. 

The authoring tools do a lot of work, and while that is not all bad, 
it should be something developers and customers are more aware of.  The
features of 
the tools to manage XML applications are more important to understand
than 
the specification because of the need to validate.  That brings up 
the subject of the number of unicorns required to approve a purchase. 
For the fresh faces, conformance tests for systems must be 
spec'd at several levels of the system and normatively declared 
in the contracts.  Remember, contract writers aren't usually 
deeply technical, so, take time to cover this subject.  
We had many similar issues with SGML procurements.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  7 18:23:10 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:39 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <3824E917.78555C71@isogen.com> (eliot@isogen.com)
References: <199911052037.VAA02691@chimay.loria.fr> <3824E917.78555C71@isogen.com>
Message-ID: <199911071821.MAA03281@bruno.techno.com>

[Eliot Kimber:]

> [...snip...] external parsed entities ("external text entities" in
> SGML parlance) are evil and should never have been included in XML.

> The only complete and managable solution to this problem is to
> manage each component as a complete and independent document and
> combine them together *semantically* using something like XLink or
> HyTime's value reference facility (explicit use-by-reference as
> distinct from hyperlinking).

Eliot is right but there is more subtlety to this story than merely
that external parsed entities are evil.  It's true that they've been
used so evilly for so long that they are hard to distinguish from the
problems that their evil uses have caused.  However, the external
parsed entity feature does have a good and beneficial purpose, which
is to make the storage structure (the way the data have been allocated
to physical containers such as computer files) of a whole document
(the bunch of stuff to be concatenated as input to the parsing
process) independent of its logical structure (as a tree of elements).
The theory is still valid: there is an element (logical) tree, and an
entity (physical storage) tree, and that in SGML or XML, the two tree
structures are not constrained by one another, which is good because
they are subject to entirely different sets of environmental
constraints.  The two structures (physical and logical) must be able
to be represented and handled in different ways simultaneously, from a
single representation in SGML and/or XML.  And external parsed
entities are a key feature for maintaining that independence.

Some people would assert that this capability is no longer needed, and
that there's no longer any such thing as a document that's large
enough to require that its source be distributed among multiple
containers (entities).  These people would assert that, given modern
computing resources, if a document is so large that it still needs to
be distributed among multiple containers, it is too damn big and
should be split up.  I suspect that they may be right, simply because
I know of no counter-example wherein a grotesquely large document is
also optimally architected.  If there's no such thing (any more) as a
non-evil document that is so large that it needs to be stored in more
than one parsed entity, then, theoretically at least, Eliot is exactly
right: external parsed entities are evil.

However, reality intrudes.  Most information is architected
suboptimally.  I think it would be a mistake to discard external
parsed entities.  I think XML needs to have features that let people
do silly things (like evilly putting all the documentation of a
weapons system into a single 190,000-page document) without causing
every XML application to blow a gasket.  We need the means to permit
evil to exist in order to avoid creating a worse evil: the perception
that XML is insufficiently robust to handle real situations, no matter
how evil they are.

The trick is for people to realize that the use of parsed external
entities should be avoided unless their use is purely for storage
convenience.  There should never be a semantic load on the fact that
some data is stored in a particular entity.  Regrettably, most of the
times when parsed external entities have been used, they have been
used for impure, semantically loaded purposes (such as the semantic of
re-usability).  So maybe as a matter of good public education policy,
Eliot's position that "external parsed entities are evil" is the right
approach, as long as we're not going to get rid of XML's ability to
support them.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov  7 20:12:56 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:39 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <199911052037.VAA02691@chimay.loria.fr>
	 <3824E917.78555C71@isogen.com> <199911071821.MAA03281@bruno.techno.com>
Message-ID: <3825DD3F.9F91566B@pacbell.net>

"Steven R. Newcomb" wrote:
> 
> Some people would assert that this capability is no longer needed, and
> that there's no longer any such thing as a document that's large
> enough to require that its source be distributed among multiple
> containers (entities).  These people would assert that, given modern
> computing resources, if a document is so large that it still needs to
> be distributed among multiple containers, it is too damn big and
> should be split up. 

Another way of looking at this:  "Some People" have very strong
assumptions about the scale of documents XML should work with.

Now, we all know that scaling assumptions like that are dangerous.
(Or if we don't, it's time to learn it!)

A better approach is to recognize the document scaling is one
of the issues that designers must deal with, external entities
are one of the tools available to manage it, and that whenever
you have lots of data to deal with you're going to have to be
very careful.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Mon Nov  8 05:38:11 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:39 2004
Subject: WML vs. XHTML
In-Reply-To: <199911070403.XAA25496@earth.isni.net>
Message-ID: <NBBBICMNIPCICMKJECCBMEDNDBAA.jelks@jelks.nu>

Ann Navarro wrote:

> >Too bad they'll never read [x]HTML pages.
>
> Never? Right now, the service provides select information proxied through a
> customized service. SprintPCS hasn't yet enabled all that can be done with
> these phones. ...

> That said, the producers of the Sprint mini-browser, phone.com, are on the
> W3C HTML WG, and are very interested in providing broad access to Web
> content, including XHTML. ...

With current generation WAP-enabled phones?

> "Never" isn't a word that's very applicable in this situation.

What do *you* think of Rohit Khare's comments about the WAP Forum?[1]  And it
would be interesting to know how Phone.com (formerly "Unwired Planet") has
responded to that article (if indeed they have responded) ...

/Jelks

[1] http://www.4k-associates.com/IEEE-L7-WAP-BIG.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jess_nemis at inod.com  Mon Nov  8 07:07:25 1999
From: jess_nemis at inod.com (jess_nemis@inod.com)
Date: Mon Jun  7 17:16:40 2004
Subject: XML Conversion
Message-ID: <9911089420.AA942044713@atrain.inod.com>

     Hello,
     
     I'm a newbie in XML Conversion and we're being tasked to transform a 
     plain text file into XML.  We've done this in SGML before and learned 
     also that XML is actually Web-enabled SGML.  However, we noticed that 
     the extensive use of taggings (elements) in XML has slowed down our 
     productivity considerably.
     
     Now my question is: is it really necessary to tag all items, say, in a 
     bibliographic reference, e.g.
     
      XML Specs now:
        
       <cite><title>The Origin of Species</title>, <author>Darwin</author> 
       <pages>pp. 6-10</pages> <pubinfo><pub>Oxford University Press</pub>,      
       <year>1901</year></pubinfo></cite>
     
      SGML Specs before:
     
      <cite>The origin of Species, Darwin, pp. 6-10, Oxford University      
      Press, 1901.</cite>
     
      Links were provided to citerefs within the document.
     
     What's the difference between the two, the rationale behind use of 
     extensive tags in XML, and when are decisions going to be made that 
     such data should or should not be tagged?
     
     Thank you all for giving these some thoughts.
     
     Regards,
     Jess Nemis
     jess_nemis@inod.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From henry_fieglein at dgbank.de  Mon Nov  8 09:16:25 1999
From: henry_fieglein at dgbank.de (henry_fieglein@dgbank.de)
Date: Mon Jun  7 17:16:40 2004
Subject: Antwort: XML Conversion
Message-ID: <C1256823.0032CEA0.00@NOY10302.dgbank.de>

I would define the DTD as follows:

<!ELEMENT cite EMPTY>
<!ATTLIST cite
 title CDATA #REQUIRED
 author CDATA #REQUIRED
 pages CDATA #REQUIRED
 publisher CDATA #REQUIRED
 pubyear CDATA #REQUIRED
>

which gives the following XML file:

<cite title="The Origin of Species" author="Darwin" pages="6-10"
publisher="Oxford University Press" pubyear="1901">

The separation of the data allows for better searching and indexing later.  It
also aides in the conversion to HTML when you want to publish it on the Web.
The XSL script to convert the data could be set based on the various library
formats.





jess_nemis@inod.com on 08.11.99 19:59:21

Bitte antworten an jess_nemis@inod.com

An:   xml-dev@ic.ac.uk
Kopie:     (Blindkopie: Henry Fieglein/F-OIHE/OI/DG BANK)
Thema:    XML Conversion




     Hello,

     I'm a newbie in XML Conversion and we're being tasked to transform a
     plain text file into XML.  We've done this in SGML before and learned
     also that XML is actually Web-enabled SGML.  However, we noticed that
     the extensive use of taggings (elements) in XML has slowed down our
     productivity considerably.

     Now my question is: is it really necessary to tag all items, say, in a
     bibliographic reference, e.g.

      XML Specs now:

       <cite><title>The Origin of Species</title>, <author>Darwin</author>
       <pages>pp. 6-10</pages> <pubinfo><pub>Oxford University Press</pub>,
       <year>1901</year></pubinfo></cite>

      SGML Specs before:

      <cite>The origin of Species, Darwin, pp. 6-10, Oxford University
      Press, 1901.</cite>

      Links were provided to citerefs within the document.

     What's the difference between the two, the rationale behind use of
     extensive tags in XML, and when are decisions going to be made that
     such data should or should not be tagged?

     Thank you all for giving these some thoughts.

     Regards,
     Jess Nemis
     jess_nemis@inod.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Andy.Bradbury at syntegra.bt.co.uk  Mon Nov  8 10:28:20 1999
From: Andy.Bradbury at syntegra.bt.co.uk (Andy.Bradbury@syntegra.bt.co.uk)
Date: Mon Jun  7 17:16:40 2004
Subject: XHTML
Message-ID: <65AF45D5E535D2118AFB0008C7FA23180C3E30@FL-EXCHANGE-03>


Would anyone care to speculate how soon/long before the XHTML specification
becomes a 'recommendation'?

Regards

Andy B.


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



From tpassin at idsonline.com  Mon Nov  8 13:53:46 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:16:40 2004
Subject: XML Conversion
References: <9911089420.AA942044713@atrain.inod.com>
Message-ID: <006201bf29f1$286618a0$81fbb1cd@tomshp>


From: <jess_nemis@inod.com>

>      Hello,
>
>      I'm a newbie in XML Conversion and we're being tasked to transform a
>      plain text file into XML.  We've done this in SGML before and learned
>      also that XML is actually Web-enabled SGML.  However, we noticed that
>      the extensive use of taggings (elements) in XML has slowed down our
>      productivity considerably.
>
>      Now my question is: is it really necessary to tag all items, say, in
a
>      bibliographic reference, e.g.
>
>       XML Specs now:
>
>        <cite><title>The Origin of Species</title>, <author>Darwin</author>
>        <pages>pp. 6-10</pages> <pubinfo><pub>Oxford University
Press</pub>,
>        <year>1901</year></pubinfo></cite>
>
>       SGML Specs before:
>
>       <cite>The origin of Species, Darwin, pp. 6-10, Oxford University
>       Press, 1901.</cite>
>
>       Links were provided to citerefs within the document.
>
>      What's the difference between the two, the rationale behind use of
>      extensive tags in XML, and when are decisions going to be made that
>      such data should or should not be tagged?
>

XML does not require any particular tags, any more the SGML did.  If you
only want to use the <cite> tag, don't use the others.  On the other hand,
some particular application or document design (DTD) may provide for more
tags because it wants to delineate more of the logical structure of the
document.  I don't know anything about the specific conversion software you
are using, but XML itself does not require any particular tags.  See if the
software will let you use only the tags you want, or look into using
something else.

Tom Passin
>      Thank you all for giving these some thoughts.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov  8 14:01:23 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:40 2004
Subject: WML vs. XHTML
References: <NBBBICMNIPCICMKJECCBMEDNDBAA.jelks@jelks.nu>
Message-ID: <002101bf29f0$d3025ae0$53beb3c7@PTGRESTON>


----- Original Message -----
From: Jelks Cabaniss <jelks@jelks.nu>
To: Ann Navarro <ann@webgeek.com>; <xml-dev@ic.ac.uk>
Sent: Monday, November 08, 1999 12:37 AM
Subject: RE: WML vs. XHTML


>
> What do *you* think of Rohit Khare's comments about the WAP Forum?[1]  And
it
> would be interesting to know how Phone.com (formerly "Unwired Planet") has
> responded to that article (if indeed they have responded) ...

I for one have read over it quickly.  The gist seems to be that the WAP
forum has bypassed existing standards and standards bodies, locking in
mobile phone users to technologies much less powerful than those in use on
the Internet. My opinions are:

1- I don't *want* to see the same XHTML content on my browser and cellphone;
I want web sites to use XML internally than translate to pretty HTML for v.
2 - v. 4 browsers, let me have the raw XML in v. 5 browsers along with a
link to a stylesheet, and translate to whatever the most appropriate format
for the other platforms (PalmPilot, mobile phones, etc.).  Sure that's more
work for the site builders, but *in principle* it's just a matter of having
a different XSLT stylesheet (XMLScript, or whatever) for each medium.

2- I'll defer to the Phone.com people on the technology; the path of least
resistance would have been to use HTTP, HTML, etc. as is. I have no idea
about the bandwidth and how quickly it will evolve to the level of the Web,
but I assume that the WAP forum didn't re-invent the lower level protocols
for their own amusement. From my playing around with WML I can easily see
that the "card deck" metaphor works better for the screen of a mobile phone
than the "document page" metaphor of the Web, so I'm comfortable with what
they did to define WML.

3 - As for bypassing the standards bodies, as someone who participates in
the W3C, I can sympathize with anyone who forms their own, highly
specialized group in order to get something that THEY need out in time to
hit a small market window.  The IETF and W3C do a great service for
humanity, but they don't exactly work on Internet time, and the WAP forum
people needed something NOW.

4. As for locking people in to soon-to-be-obsolete technology, the WAP Forum
may or may not be guilty here, I don't know.  I do STRONGLY believe that the
underlying XML technologies let specific site builders "future proof"
themselves by separating structure and content from form.  XHTML has a place
in easing the migration from the messy HTML that's out on theWeb now to a
more XML-centric world, but it's place in my scheme of things is *parallel*
to WML as one of several output formats sites will want to transform their
content into.  I don't see XHTML as a universal output format that should
work well on all platforms...

In other words, the title of this thread "WML vs XHTML" seems like a
misnomer to me: WML is an XML output format for small screen, low bandwidth
devices, and XHTML is an XML output format for standard screen, relatively
high bandwidth devices.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rgl at decisionsoft.com  Mon Nov  8 14:21:51 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:16:40 2004
Subject: WML vs. XHTML
In-Reply-To: <002101bf29f0$d3025ae0$53beb3c7@PTGRESTON>
Message-ID: <Pine.LNX.4.10.9911081413450.1216-100000@localhost.localdomain>

On Mon, 8 Nov 1999, Michael Champion wrote:

> 4. As for locking people in to soon-to-be-obsolete technology, the WAP Forum
> may or may not be guilty here, I don't know.  I do STRONGLY believe that the
> underlying XML technologies let specific site builders "future proof"
> themselves by separating structure and content from form.

I think you're probably right here.

For a start, although WAP and WML were designed by the same organisation,
they're independent entities. If the mobile phone companies do one day
decide to change the underlying WAP protocols, it needn't make any
difference at all to those who provide WML content - only to those who run
a WAP gateway.

Even if they decide to change WML, most people will have implemented WML
using generic XML tools, so provided the change simply moves from the
current WML spec to some other XML spec, any problems shouldn't be too
difficult to solve.

The real problem in wireless technology as far as content providers are
concerned is figuring out the best way to display data on an incredibly
small screen...

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 14:25:31 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun  7 17:16:40 2004
Subject: WML vs. XHTML
In-Reply-To: <NBBBICMNIPCICMKJECCBMEDNDBAA.jelks@jelks.nu>
References: <199911070403.XAA25496@earth.isni.net>
Message-ID: <4.1.19991108092446.0209e140@mail.webgeek.com>

At 12:37 AM 11/8/99 -0500, Jelks Cabaniss wrote:

>What do *you* think of Rohit Khare's comments about the WAP Forum?[1]  And it
>would be interesting to know how Phone.com (formerly "Unwired Planet") has
>responded to that article (if indeed they have responded) ...

One consultant's opinion, which is now rather dated, viewed in Web time. 

The "conclusions" regarding XHTML are suspect. 

Quite frankly, much of it sounds like some of the more paranoid rantings
here :)

Ann
---

Author of:  Effective Web Design: Master the Essentials
10/99 - Mastering XML, 12/99 - HTML By Example, 2nd. Ed.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  8 15:08:05 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:40 2004
Subject: XHTML 1.0 returned to HTML WG
References: <003901bf271e$fe5a5be0$099918d1@docuverse1> <3822FC81.D077B6F7@prescod.net> <m3iu3givwn.fsf@localhost.localdomain>
Message-ID: <3825E52F.31E71581@prescod.net>

David Megginson wrote:
> 
> Paul Prescod <paul@prescod.net> writes:
> 
> > "SGML may now be used on the Web. DOCTYPE
> > declarations are now optional. Otherwise, use your common sense."
> 
> Well, I would have made it a couple paragraphs longer, but in essence,
> that might have served, except for two problems:

My main question isn't about whether XML should be standalone or a
derivative of SGML. My question is: "Why do you agree with formal
standards sometimes and then other times say that we should just depend
on 'common sense'?" My personal opinion is that anywhere
interoperability is truly required, it should be formally specified. I
mean the main argument against the infoset (and groves before the
infoset, and ESIS before groves) was: "Well that's all common sense,
isn't it?"

Put it this way: if something technical truly is common sense then it
must be simple. If it is simple it is simple to make a specification for
it. So why not engage in that simple exercise to protect ourselves from
lock-in? 

The problem is that this issue of extending HTML is *not* simple. People
want to use HTML snippets in radically different and incompatible ways.
We could just close our eyes, standardize a namespace and hope it all
works out for the best but I strongly suspect that it will not. I
believe history is on my side.

> p.s. Shouldn't that be "duct tape", Paul and Don?  We don't want the
>      SPCA down on us.

I just copied Don. So much for my common sense. :)

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

When I'm gone, boxing will be nothing again.  The fans with the cigars
and the hats turned down'll be there, but no more housewives and little
men in the street and foreign presidents.  ... I was the onliest boxer
in history people asked questions like a senator. -- Muhammad Ali



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  8 15:32:10 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:40 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <199911052037.VAA02691@chimay.loria.fr> <3824E917.78555C71@isogen.com> <199911071821.MAA03281@bruno.techno.com>
Message-ID: <3826ECCB.DFC22905@prescod.net>



"Steven R. Newcomb" wrote:
> ... 
> 
> However, reality intrudes.  Most information is architected
> suboptimally.  I think it would be a mistake to discard external
> parsed entities.  I think XML needs to have features that let people
> do silly things (like evilly putting all the documentation of a
> weapons system into a single 190,000-page document) without causing
> every XML application to blow a gasket.  

Just about every XML application will blow a gasket with or without
external parsed entities. The "applications" that external parsed
entities help are file transmission and storage applications: browsers,
file transfer engines and file systems. These software components
typically have MUCH GREATER CAPACITIES than the applications that work
with the XML logical structure. With all due respect, I feel more
comfortable using FTP to transfer a 1 GB document than I would stuffing
that into Excelon, Internet Explorer, an XSLT engine or anything else
that works with the logical model (other than SAX).

> We need the means to permit
> evil to exist in order to avoid creating a worse evil: the perception
> that XML is insufficiently robust to handle real situations, no matter
> how evil they are.

XML tools *are* insufficiently robust and external entities in no way
help to alleviate that problem. If anything, they make the problem worse
by encouraging people to make their XML documents larger than tools can
handle. A component approach is much safer.

On the other hand, while I agree with Eliot that external entities are
more hassle than they are worth, they are occasionally useful on
smallish problems where you can manage the ID namespace manually and
want separate editing of chapters etc. In other words, since we have
them one shouldn't avoid them supersitiously. Just learn what they are
good for (small, hand-maintained projects) and not good for (large scale
component reuse). If I could take them out, I would though.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
http://www.capitol.state.tx.us/txconst/sections/cn000100-000400.html

"No religious test shall ever be required as a qualification to any
office, or public trust, in this State; nor shall any one be
excluded from holding office on account of his religious sentiments,
provided he acknowledge the existence of a Supreme Being."
                         - Texas Constitution, Article 1, Section 4

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



From mallinathn at mastek.com  Mon Nov  8 15:38:39 1999
From: mallinathn at mastek.com (Mallinath)
Date: Mon Jun  7 17:16:40 2004
Subject: unsubscribe
Message-ID: <003b01bf29d5$504204e0$1b0dc5aa@ws-dal-m8929.sealand.csx.com>

unsubscribe


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 16:03:10 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:40 2004
Subject: XML Conversion
References: <9911089420.AA942044713@atrain.inod.com>
Message-ID: <3826F191.7A95@hiwaay.net>

jess_nemis@inod.com wrote:
> 
>      Now my question is: is it really necessary to tag all items, say, in a
>      bibliographic reference, 

The idea is to tag that which you want to identify later by logical 
location if the logical structure is the means for establishing a 
persistent identity.

In effect, XML does not care how much tagging you use. 
You have to determine the requirements of the information in the 
dimensions in which that information participates and by which it 
may be referenced.  A reference by unambigous name value is the 
easiest.  Having the logical structure and the name it provides 
may not be optimal for other processes/dimensions.  You can 
use non-name link and location types such as counting in a 
text string (eg, split) but as the complexity of naming decreases, 
there is usually a complementary increase in the complexity 
of processing to locate a unique item.  Uniqueness and 
persistence are the requirements for identity.

It is a level of detail issue.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 16:03:13 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:40 2004
Subject: XHTML 1.0 returned to HTML WG
References: <003901bf271e$fe5a5be0$099918d1@docuverse1> <3822FC81.D077B6F7@prescod.net> <m3iu3givwn.fsf@localhost.localdomain> <3825E52F.31E71581@prescod.net>
Message-ID: <3826F31C.2C5F@hiwaay.net>

Paul Prescod wrote:
>
> Put it this way: if something technical truly is common sense then it
> must be simple. If it is simple it is simple to make a specification for
> it. So why not engage in that simple exercise to protect ourselves from
> lock-in?

Lock in is not as much an issue (it is a market phenomenon that is hard
to 
avoid).   

The issue is the record of authority to be cited when specifying 
and procuring systems.  The record of authority is itself, a namespace
and 
must be rational with respect to resolving referenced.   It was an issue
with 
specifying SGML systems, as noted in another thread:  even with a
tighter 
standard, we needed conformance tests to procure systems that were used 
at larger scales of production.  This is the same for XML, namespaces, 
etc.  We must enable professionals whose jobs are aligned with ours to 
contract for systems and products of these systems without having to 
be deeply aware of the technical details.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov  8 16:29:58 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:16:40 2004
Subject: bibiography dtd?
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F2780B0@MDYNYCMSX1>

The bibliography element type (and sub-elements) of the DocBook DTD may suit
your needs, especially after a little customization. See www.docbook.org
and, in particular, http://www.docbook.org/tdg/html/bibliography.html.

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii

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



From cviswana at RCCL.COM  Mon Nov  8 16:54:08 1999
From: cviswana at RCCL.COM (Chandramouli Viswanathan)
Date: Mon Jun  7 17:16:40 2004
Subject: Microsoft XML Parser
Message-ID: <85256823.005C9CAD.00@RCCL.COM>




Hi All,
We are using the MSXML DOM parser to validate our xml document against DTD's.
We are using an external entity reference for the DOCTYPE entity to point to the
DTD.

The parser validation is successful when we use it this way:
<!DOCTYPE SYSTEM .......................

But we require to change it to a public reference as we share the DTD across
multiple systems. So the desired format for the external doctype reference is
like:
<!DOCTYPE Msg PUBLIC "//COMPANY//SUBSYSTEMID//DTD//Transaction Name//EN"
"dtd_name.dtd">

My question is ---- how can i provide the mapping to the physical dtd file on
some network area based on the public reference we are using? according to the
w3c standards for validation, there is supposed to be a catalog file where you
can drop this reference. I have not been able to figure out from microsoft and
third party documentation on how to setup this mapping.

Any help / suggestions is most appreciated

Regards,
Mouli



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 17:25:55 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:40 2004
Subject: Microsoft XML Parser
References: <85256823.005C9CAD.00@RCCL.COM>
Message-ID: <38270780.9FB96E6@pacbell.net>

Chandramouli Viswanathan wrote:
> 
> My question is ---- how can i provide the mapping to the physical dtd file on
> some network area based on the public reference we are using? according to the
> w3c standards for validation, there is supposed to be a catalog file where you
> can drop this reference. I have not been able to figure out from microsoft and
> third party documentation on how to setup this mapping.

Actually what the XML spec says is that you "may" have functionality
(regardless of whether you're validating) along the lines of what SGML
systems do with catalogs.  It doesn't mention catalogs, as I recall.

There's no requirement that any parser have catalog support.  Any SAX
parser can kick it in easily (use an EntityResolver) but you're not
using one of those.

Your duty, should you choose to accept it, is to persuate Microsoft
that this feature is worth having ... and that they should use a
standard catalog format so that it's not a proprietary feature!

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jchalfan at outbackinc.com  Mon Nov  8 19:06:22 1999
From: jchalfan at outbackinc.com (Jay Chalfant)
Date: Mon Jun  7 17:16:41 2004
Subject: Lightweight XML
Message-ID: <9D7F61B87714D31194530090276212440C988F@outback.internal.outbackinc.com>

In working on thin clients over thin pipes, I've had two notions regarding
XML:

1) Compressed XML: Not generic text compression, but DTD-specific
compression. It seems that if I have a document that conforms to a given DTD
that I could apply a generic transform (input DTD and document) that would
produce a minimal representation of the document. Readers of the document
would need to know the DTD and the generic transform used. Anybody know of
such a transform or work in this area?

2) Lightweight parser: If I am building a system that uses a single DTD,
there should exist the potential to produce a parser that is much lighter
that a standard (non-validating) parser. Does anybody know of a tool that
would accept DTD as input and produce source code for the "single-DTD"
parser?

All comments welcome. Thanks.

-J

----------------------------
Jay Chalfant
OutBack Resource Group, Inc.
jchalfan@outbackinc.com
Voice: 805-542-8570 x15
Fax:   805-541-5467 


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



From Curt.Arnold at hyprotech.com  Mon Nov  8 19:50:52 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:16:41 2004
Subject: New Schema Working Draft at W3C
Message-ID: <61DAD58E8F4ED211AC8400A0C9B4687341548E@THOR>

There is a new XML Schema working draft dated November 5 at
http://www.w3.org/tr.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 20:02:27 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:41 2004
Subject: Why do we write standards?
In-Reply-To: Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600"
References: <003901bf271e$fe5a5be0$099918d1@docuverse1> <3822FC81.D077B6F7@prescod.net> <m3iu3givwn.fsf@localhost.localdomain> <3825E52F.31E71581@prescod.net>
Message-ID: <m33duhcszh.fsf_-_@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> My main question isn't about whether XML should be standalone or a
> derivative of SGML. My question is: "Why do you agree with formal
> standards sometimes and then other times say that we should just
> depend on 'common sense'?" My personal opinion is that anywhere
> interoperability is truly required, it should be formally
> specified. I mean the main argument against the infoset (and groves
> before the infoset, and ESIS before groves) was: "Well that's all
> common sense, isn't it?"

That's a fair question.  The short answer is that I disagree with your
opinion -- standardization is a kind of regulation, and deciding when
and how to regulate is a very difficult balancing act between benefits
(the Socialist view) and costs (the Libertarian view).

Here's the long answer:

When you standardize, the benefits that you hope to achieve stem
mainly from the network effect -- lower development costs and greater
interoperability spring immediately to mind.  These benefits are so
powerful (and so tempting) that they often lead people to rush to
standardization.

On the other hand, standardization has many costs, of which the most
obvious are the initial cost of implementing more than you need to
(since standards are necessarily a superset of the needs of any
specific set of users) and the risk of committing to an inappropriate
solution prematurely and squashing real innovation.

If a standard is successful, the network effect can more than
compensate for the negatives, but most standards simply fail and leave
the early implementors out of pocket.  The problem is that,
traditionally, standardization has solved existing problems: everyone
had trains but they could not run on the same rail gauge, or there
were many different phone companies but customers from one could not
call customers from another another, or every public house used a
different sized glass so it wasn't possible to compare prices.

Now that we're trying to standardize in *advance* of implementation,
we run an enormous risk of messing up: our industry simply lacks any
real, large-scale implementation experience to guide the process, so
we're just publishing our own wild speculations and stamping them as
W3C Recommendations or ISO standards or what-have-you.

The solution is to standardize incrementally to minimize the risks,
and to concentrate initially on the areas that will bring the most
benefit for the least effort.

Since we know so little about mixing HTML into other vocabularies
right now, and since we know almost nothing about how XML will be used
in Web clients, I think that it makes sense to start by standardizing
only a little bit.  Let's give people a standard Namespace (and the
name case) and then let them start experimenting -- in a year or two,
if there's enough demand and if we understand the problem space a
little better, we can try standardizing one step further, but even
then there will always be a point beyond which the costs of
standardization outweigh the benefits.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From w.hedley at auckland.ac.nz  Mon Nov  8 20:53:10 1999
From: w.hedley at auckland.ac.nz (Warren Hedley)
Date: Mon Jun  7 17:16:41 2004
Subject: bibiography dtd?
References: <51ED3F5356D8D011A0B1006097C3073401B16F4D@martinique>
Message-ID: <38273806.E06D349F@auckland.ac.nz>

Hi Gregg

I faced the same problem as you 6 months ago (actually, I'm just
ignoring it now), and had a look at the docbook DTD but found it
too vast and complicated to follow initially. I ended up cutting
out just the bibliography section for inclusion into my own DTDs.
That DTD module is included below - if this wraps unusably in
your mail window (as has been known to happen), let me know, and
I'll send it to you as an attachment.

If you spot anything simpler, or pretty much any other bibliography
DTDs, please let me know.

Hope this helps.


<!--****************************************************************************
FILE : cell-references.mod

AUTHOR : Warren Hedley
         Department of Engineering Science
         University of Auckland

CREATED : 22 March 1999

LAST MODIFIED : 23 March 1999

  This DTD module defines the elements associated with making references to
books or articles from CellML. It is a stripped down version of the DocBook
"dbpoolx.mod", removing references to other modules, and some extraneous
elements. The top level element is <biblioentry>, which should be used for
all referencing. This requires "cell-basic.mod" to be included for some
attributes.

It is possible there are bugs in this module - some elements have been removed
or have been listed in content models and then not defined. Please report bugs
to the author (see above).

The source DocBook modules (in XML form) can be found at
   http://nwalsh.com/docbook/
and the original SGML DocBook comes from
   http://www.oasis-open.org/docbook/

CHANGES :
=============================================================================-->

<!ENTITY % docbook.core.attrs
 "id       ID      #IMPLIED
  xmlns    CDATA   #FIXED 'http://www.oasis-open.org/docbook/'">

<!-- ...................................................................... -->
<!-- Bibliographic entities and elements .................................. -->

<!-- The bibliographic elements are typically used in the document
     hierarchy. They do not appear in content models of information
     pool elements.  See also the document information elements,
     below. -->

<!-- note : the <authorblurb> element was removed -->
<!ENTITY % person.ident.mix
		"honorific|firstname|surname|lineage|othername|affiliation|contrib">

<!ENTITY % bibliocomponent.mix
		"abbrev|abstract|address|artpagenums|author
		|authorgroup|authorinitials
		|collab|confgroup|contractnum|contractsponsor
		|copyright|corpauthor|corpname|date|edition
		|editor|invpartnumber|isbn|issn|issuenum|orgname
		|othercredit|pagenums|printhistory|productname
		|productnumber|pubdate|publisher|publishername
		|pubsnumber|releaseinfo|revhistory|seriesvolnums
		|subtitle|title|titleabbrev|volumenum
		|%person.ident.mix;">

<!ELEMENT biblioentry ((artheader | bookbiblio | seriesinfo
	| (%bibliocomponent.mix;))+)>
<!ATTLIST biblioentry %docbook.core.attrs;>

<!ELEMENT bookbiblio ((%bibliocomponent.mix; | seriesinfo)+)>
<!ATTLIST bookbiblio %docbook.core.attrs;>

<!ELEMENT seriesinfo ((%bibliocomponent.mix;)+)>
<!ATTLIST seriesinfo %docbook.core.attrs;>

<!ELEMENT artheader ((%bibliocomponent.mix; | bookbiblio)+)>
<!ATTLIST artheader %docbook.core.attrs;>



<!-- Personal identity elements ....... -->

<!-- These elements are used only within Author, Editor, and 
OtherCredit. -->

<!ELEMENT contrib (#PCDATA)>
<!ATTLIST contrib %docbook.core.attrs;>

<!ELEMENT firstname (#PCDATA)>
<!ATTLIST firstname %docbook.core.attrs;>

<!ELEMENT honorific (#PCDATA)>
<!ATTLIST honorific %docbook.core.attrs;>

<!ELEMENT lineage (#PCDATA)>
<!ATTLIST lineage %docbook.core.attrs;>

<!ELEMENT othername (#PCDATA)>
<!ATTLIST othername %docbook.core.attrs;>

<!ELEMENT surname (#PCDATA)>
<!ATTLIST surname %docbook.core.attrs;>

<!ELEMENT affiliation (shortaffil?, jobtitle*, orgname?, orgdiv*, address*)>
<!ATTLIST affiliation %docbook.core.attrs;>

<!ELEMENT shortaffil (#PCDATA)>
<!ATTLIST shortaffil %docbook.core.attrs;>

<!ELEMENT jobtitle (#PCDATA)>
<!ATTLIST jobtitle %docbook.core.attrs;>


<!-- biblioentry children ............. -->

<!-- Address .......................... -->

<!ELEMENT address (#PCDATA|street|pob|
  postcode|city|state|country|phone|fax|email|otheraddr)*>
<!ATTLIST address %docbook.core.attrs;>

<!ELEMENT street (#PCDATA)>
<!ATTLIST street %docbook.core.attrs;>

<!ELEMENT pob (#PCDATA)>
<!ATTLIST pob %docbook.core.attrs;>

<!ELEMENT postcode (#PCDATA)>
<!ATTLIST postcode %docbook.core.attrs;>

<!ELEMENT city (#PCDATA)>
<!ATTLIST city %docbook.core.attrs;>

<!ELEMENT state (#PCDATA)>
<!ATTLIST state %docbook.core.attrs;>

<!ELEMENT country (#PCDATA)>
<!ATTLIST country %docbook.core.attrs;>

<!ELEMENT phone (#PCDATA)>
<!ATTLIST phone %docbook.core.attrs;>

<!ELEMENT fax (#PCDATA)>
<!ATTLIST fax %docbook.core.attrs;>

<!ELEMENT email (#PCDATA)>
<!ATTLIST email %docbook.core.attrs;>

<!ELEMENT otheraddr (#PCDATA)>
<!ATTLIST otheraddr %docbook.core.attrs;>

<!-- ArtPageNums ...................... -->

<!ELEMENT artpagenums (#PCDATA)>
<!ATTLIST artpagenums %docbook.core.attrs;>

<!-- Author ........................... -->

<!ELEMENT author ((%person.ident.mix;)+)>
<!ATTLIST author %docbook.core.attrs;>

<!-- AuthorGroup ...................... -->

<!ELEMENT authorgroup ((author|editor|collab|corpauthor|othercredit)+)>
<!ATTLIST authorgroup %docbook.core.attrs;>

<!ELEMENT collab (collabname, affiliation*)>
<!ATTLIST collab %docbook.core.attrs;>

<!ELEMENT collabname (#PCDATA)>
<!ATTLIST collabname %docbook.core.attrs;>

<!-- AuthorInitials ................... -->

<!ELEMENT authorinitials (#PCDATA)>
<!ATTLIST authorinitials %docbook.core.attrs;>

<!-- ConfGroup ........................ -->

<!ELEMENT confgroup ((confdates|conftitle|confnum|address|confsponsor)*)>
<!ATTLIST confgroup %docbook.core.attrs;>

<!ELEMENT confdates (#PCDATA)>
<!ATTLIST confdates %docbook.core.attrs;>

<!ELEMENT conftitle (#PCDATA)>
<!ATTLIST conftitle %docbook.core.attrs;>

<!ELEMENT confnum (#PCDATA)>
<!ATTLIST confnum %docbook.core.attrs;>

<!ELEMENT confsponsor (#PCDATA)>
<!ATTLIST confsponsor %docbook.core.attrs;>

<!-- ContractNum ...................... -->

<!ELEMENT contractnum (#PCDATA)>
<!ATTLIST contractnum %docbook.core.attrs;>

<!-- ContractSponsor .................. -->

<!ELEMENT contractsponsor (#PCDATA)>
<!ATTLIST contractsponsor %docbook.core.attrs;>

<!-- Copyright ........................ -->

<!ELEMENT copyright (year+, holder*)>
<!ATTLIST copyright %docbook.core.attrs;>

<!ELEMENT year (#PCDATA)>
<!ATTLIST year %docbook.core.attrs;>

<!ELEMENT holder (#PCDATA)>
<!ATTLIST holder %docbook.core.attrs;>

<!-- CorpAuthor ....................... -->

<!ELEMENT corpauthor (#PCDATA)>
<!ATTLIST corpauthor %docbook.core.attrs;>

<!-- CorpName ......................... -->

<!ELEMENT corpname (#PCDATA)>
<!ATTLIST corpname %docbook.core.attrs;>

<!-- Date ............................. -->

<!ELEMENT date (#PCDATA)>
<!ATTLIST date %docbook.core.attrs;>

<!-- Edition .......................... -->

<!ELEMENT edition (#PCDATA)>
<!ATTLIST edition %docbook.core.attrs;>

<!-- Editor ........................... -->

<!ELEMENT editor ((%person.ident.mix;)+)>
<!ATTLIST editor %docbook.core.attrs;>

<!-- ISBN ............................. -->

<!ELEMENT isbn (#PCDATA)>
<!ATTLIST isbn %docbook.core.attrs;>

<!-- ISSN ............................. -->

<!ELEMENT issn (#PCDATA)>
<!ATTLIST issn %docbook.core.attrs;>

<!-- InvPartNumber .................... -->

<!ELEMENT invpartnumber (#PCDATA)>
<!ATTLIST invpartnumber %docbook.core.attrs;>

<!-- IssueNum ......................... -->

<!ELEMENT issuenum (#PCDATA)>
<!ATTLIST issuenum %docbook.core.attrs;>

<!-- LegalNotice ...................... -->

<!ELEMENT legalnotice (#PCDATA)>
<!ATTLIST legalnotice %docbook.core.attrs;>

<!-- OrgName .......................... -->

<!ELEMENT orgname (#PCDATA)>
<!ATTLIST orgname %docbook.core.attrs;>

<!-- OrgDiv ........................... -->

<!ELEMENT orgdiv (#PCDATA)>
<!ATTLIST orgdiv %docbook.core.attrs;>

<!-- OtherCredit ...................... -->

<!ELEMENT othercredit ((%person.ident.mix;)+)>
<!ATTLIST othercredit %docbook.core.attrs;>

<!-- PageNums ......................... -->

<!ELEMENT pagenums (#PCDATA)>
<!ATTLIST pagenums %docbook.core.attrs;>

<!-- PrintHistory ..................... -->

<!ELEMENT printhistory (#PCDATA)>
<!ATTLIST printhistory %docbook.core.attrs;>

<!-- ProductName ...................... -->

<!ELEMENT productname (#PCDATA)>
<!ATTLIST productname %docbook.core.attrs;
  class (service|trade|registered|copyright)	'trade'>

<!-- ProductNumber .................... -->

<!ELEMENT productnumber (#PCDATA)>
<!ATTLIST productnumber %docbook.core.attrs;>

<!-- PubDate .......................... -->

<!ELEMENT pubdate (#PCDATA)>
<!ATTLIST pubdate %docbook.core.attrs;>

<!-- Publisher ........................ -->

<!ELEMENT publisher (publishername, address*)>
<!ATTLIST publisher %docbook.core.attrs;>

<!ELEMENT publishername (#PCDATA)>
<!ATTLIST publishername %docbook.core.attrs;>

<!-- PubsNumber ....................... -->

<!ELEMENT pubsnumber (#PCDATA)>
<!ATTLIST pubsnumber %docbook.core.attrs;>

<!-- ReleaseInfo ...................... -->

<!ELEMENT releaseinfo (#PCDATA)>
<!ATTLIST releaseinfo %docbook.core.attrs;>

<!-- RevHistory ....................... -->

<!ELEMENT revhistory (revision+)>
<!ATTLIST revhistory %docbook.core.attrs;>

<!ELEMENT revision (revnumber, date, authorinitials*, revremark?)>
<!ATTLIST revision %docbook.core.attrs;>

<!ELEMENT revnumber (#PCDATA)>
<!ATTLIST revnumber %docbook.core.attrs;>

<!ELEMENT revremark (#PCDATA)>
<!ATTLIST revremark %docbook.core.attrs;>

<!-- SeriesVolNums .................... -->

<!ELEMENT seriesvolnums (#PCDATA)>
<!ATTLIST seriesvolnums %docbook.core.attrs;>

<!-- VolumeNum ........................ -->

<!ELEMENT volumenum (#PCDATA)>
<!ATTLIST volumenum %docbook.core.attrs;>

<!-- ...................................................................... -->
<!-- Title elements ....................................................... -->

<!ELEMENT title (#PCDATA)>
<!ATTLIST title %docbook.core.attrs;>

<!ELEMENT titleabbrev (#PCDATA)>
<!ATTLIST titleabbrev %docbook.core.attrs;>

<!ELEMENT subtitle (#PCDATA)>
<!ATTLIST subtitle %docbook.core.attrs;>

<!-- General words and phrases ............................................ -->

<!ELEMENT abbrev (#PCDATA)>
<!ATTLIST abbrev %docbook.core.attrs;>

<!-- ...................................................................... -->
<!-- Paragraph-related elements ........................................... -->

<!ELEMENT abstract (#PCDATA)>
<!ATTLIST abstract %docbook.core.attrs;>




-- 
Warren Hedley
Department of Engineering Science
Auckland University
New Zealand

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 21:34:06 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:41 2004
Subject: bibiography dtd?
References: <51ED3F5356D8D011A0B1006097C3073401B16F4D@martinique> <38273806.E06D349F@auckland.ac.nz>
Message-ID: <382740A3.788A@hiwaay.net>

Warren Hedley wrote:
> 
> Hi Gregg
> 
> I faced the same problem as you 6 months ago (actually, I'm just
> ignoring it now), and had a look at the docbook DTD but found it
> too vast and complicated to follow initially. I ended up cutting
> out just the bibliography section for inclusion into my own DTDs.

Good approach.  Question: is it a valid subset?  Will any instance that 
parses by this definition parse with the original?

How should an XML DTD designer signify that this DTD is a 
conformant subset or a variant of a another DTD?  Are 
these one, two, or three namespaces IF a namespace identifier 
resolves to a schema?  This matters if the FPI is ROA for the 
DTD and a label for the namespace identifier.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gorden at bnl.gov  Mon Nov  8 22:07:17 1999
From: gorden at bnl.gov (Gorden-Ozgul, Patricia E)
Date: Mon Jun  7 17:16:41 2004
Subject: bibiography dtd?
Message-ID: <698DB793D712D31180B600902746422D8475C4@exchange01.bnl.gov>

I have an industry-provided bibliographic DTD to which I need to apply data
from Word documents.  Other than a manual solution (clerical cut/paste from
Word doc to DTD doc) how would one create the DTD ASCII file for the data
exchange.

This may seem like a dumb question, but I am new to this 'document
processing' field.

TIA

____________________________________
Pat Gorden-Ozgul					
Sr. Systems Specialist			
(631)344-5159					
gorden@bnl.gov				

Brookhaven National Laboratory
Database Development Group
Information Services Division - Bldg. 477
Upton, New York   11967


. -----Original Message-----
. From: Len Bullard [mailto:cbullard@hiwaay.net]
. Sent: Monday, November 08, 1999 4:29 PM
. To: Warren Hedley
. Cc: Reynolds, Gregg; 'xml-dev@ic.ac.uk'
. Subject: Re: bibiography dtd?
. 
. 
. Warren Hedley wrote:
. > 
. > Hi Gregg
. > 
. > I faced the same problem as you 6 months ago (actually, I'm just
. > ignoring it now), and had a look at the docbook DTD but found it
. > too vast and complicated to follow initially. I ended up cutting
. > out just the bibliography section for inclusion into my own DTDs.
. 
. Good approach.  Question: is it a valid subset?  Will any 
. instance that 
. parses by this definition parse with the original?
. 
. How should an XML DTD designer signify that this DTD is a 
. conformant subset or a variant of a another DTD?  Are 
. these one, two, or three namespaces IF a namespace identifier 
. resolves to a schema?  This matters if the FPI is ROA for the 
. DTD and a label for the namespace identifier.
. 
. 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
. unsubscribe xml-dev
. To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gorden at bnl.gov  Mon Nov  8 22:10:56 1999
From: gorden at bnl.gov (Gorden-Ozgul, Patricia E)
Date: Mon Jun  7 17:16:41 2004
Subject: bibiography dtd?
Message-ID: <698DB793D712D31180B600902746422D8475C5@exchange01.bnl.gov>

Sorry if this is a duplicate posting!

____________________________________
Pat Gorden-Ozgul					
Sr. Systems Specialist			
(631)344-5159					
gorden@bnl.gov				

Brookhaven National Laboratory
Database Development Group
Information Services Division - Bldg. 477
Upton, New York   11967


. -----Original Message-----
. From: Gorden-Ozgul, Patricia E 
. Sent: Monday, November 08, 1999 5:05 PM
. To: 'xml-dev@ic.ac.uk'
. Subject: RE: bibiography dtd?
. 
. 
. I have an industry-provided bibliographic DTD to which I need 
. to apply data from Word documents.  Other than a manual 
. solution (clerical cut/paste from Word doc to DTD doc) how 
. would one create the DTD ASCII file for the data exchange.
. 
. This may seem like a dumb question, but I am new to this 
. 'document processing' field.
. 
. TIA
. 
. ____________________________________
. Pat Gorden-Ozgul					
. Sr. Systems Specialist			
. (631)344-5159					
. gorden@bnl.gov				
. 
. Brookhaven National Laboratory
. Database Development Group
. Information Services Division - Bldg. 477
. Upton, New York   11967
. 
. 
. . -----Original Message-----
. . From: Len Bullard [mailto:cbullard@hiwaay.net]
. . Sent: Monday, November 08, 1999 4:29 PM
. . To: Warren Hedley
. . Cc: Reynolds, Gregg; 'xml-dev@ic.ac.uk'
. . Subject: Re: bibiography dtd?
. . 
. . 
. . Warren Hedley wrote:
. . > 
. . > Hi Gregg
. . > 
. . > I faced the same problem as you 6 months ago (actually, I'm just
. . > ignoring it now), and had a look at the docbook DTD but found it
. . > too vast and complicated to follow initially. I ended up cutting
. . > out just the bibliography section for inclusion into my own DTDs.
. . 
. . Good approach.  Question: is it a valid subset?  Will any 
. . instance that 
. . parses by this definition parse with the original?
. . 
. . How should an XML DTD designer signify that this DTD is a 
. . conformant subset or a variant of a another DTD?  Are 
. . these one, two, or three namespaces IF a namespace identifier 
. . resolves to a schema?  This matters if the FPI is ROA for the 
. . DTD and a label for the namespace identifier.
. . 
. . 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
. . unsubscribe xml-dev
. . To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From leeanne at leeanne.com  Mon Nov  8 22:23:21 1999
From: leeanne at leeanne.com (Lee Anne Phillips)
Date: Mon Jun  7 17:16:41 2004
Subject: Why do we write standards?
In-Reply-To: <m33duhcszh.fsf_-_@localhost.localdomain>
References: <Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600">
 <003901bf271e$fe5a5be0$099918d1@docuverse1>
 <3822FC81.D077B6F7@prescod.net>
 <m3iu3givwn.fsf@localhost.localdomain>
 <3825E52F.31E71581@prescod.net>
Message-ID: <4.2.0.58.19991108123423.00a1ccf0@shell16.ba.best.com>

At Monday 11/8/99 03:01 AM -0500, David Megginson wrote:
>Paul Prescod <paul@prescod.net> writes:
> > My main question isn't about whether XML should be standalone or a
> > derivative of SGML. My question is: "Why do you agree with formal
> > standards sometimes and then other times say that we should just
> > depend on 'common sense'?" My personal opinion is that anywhere
> > interoperability is truly required, it should be formally
> > specified. I mean the main argument against the infoset (and groves
> > before the infoset, and ESIS before groves) was: "Well that's all
> > common sense, isn't it?"
>
>That's a fair question.  The short answer is that I disagree with your
>opinion -- standardization is a kind of regulation, and deciding when
>and how to regulate is a very difficult balancing act between benefits
>(the Socialist view) and costs (the Libertarian view).

I would disagree with the characterization of standardization as a 
Socialist/Libertarian dichotomy. Standards are not regulations in any sense 
of the word. Standards are primarily developed and *voluntarily* adhered to 
by commercial, capitalist interests. SAE sizing of nuts and bolts were a 
capitalist invention that eventually put an end to individual crafting of 
complete articles of trade and ushered in the era of factories, 
interchangeable parts, and mass production. In short, civilization as we 
know it.

The W3C standards process is driven by commercial interests. They're the 
people who fund it, just as SAE was funded by industry. They may kick and 
scream individually about their favorite innovations but when push comes to 
shove they toe the line. Even Microsoft supports ECMAScript, now that it 
doesn't have Netscape stamped all over it.

The growing ubiquity of the Web is driving the same process in data-stream 
plug-compatibility as mass production drove parts compatibility. Businesses 
see their own enlightened self-interest coincide with the availability of 
cheap computers, cheap web tools, and cheap browsers, all plug compatible. 
The people interested in standardization are not some mythical Soviet 
Collective staffed by vodka-pickled and caviar-stuffed Commissars, but 
hard-headed business people with their eye on the bottom line.

The reason the Web has taken off is that it promises data-stream ubiquity 
and connectivity, freeing businesses from dependence on proprietary 
technologies. XML is on the plate of every database company I've talked to. 
Because it promises a *useful* format for making their proprietary 
technology available to everyone in the world. Major customers are 
*demanding* it, even before it's fully standardized, because their 
*yearning* for multiple suppliers and second sources is so strong that 
they're calling it into existence by sheer willpower.

Standards drive down the cost of labor as well as the cost of supplies. 
Cars went from the luxury playthings of the very wealthy to the essentials 
of the working class because *voluntary* standards drove down the cost of 
producing them to the point that almost everyone could afford them. Nobody 
"regulated" bolt sizes. To this day you're perfectly free to create any 
size bolt you want. You just can't sell it anywhere, except perhaps to a 
bolt collector, or perhaps a nut. ;-)

The quality of a bolt is measured by how closely it adheres to standards. 
Cheap bolts vary slightly, as everyone knows. The cheaper the bolt the more 
it varies and the harder it is to find wrenches that fit correctly. Right 
now we've got a lot of cheap browsers out there, thrown together in haste 
and with almost non-existent quality. Real companies aren't happy about it.

Far too much of current Web and data design practice is involved in making 
metaphorical wrenches to fit proprietary bolt sizes from every 
manufacturer.  The business community as a whole doesn't like it. They'd 
far prefer a world in which they could depend on things working 
interchangeably. And it *will* happen. That's where the money is. Even 
Microsoft will be forced to go along, one way or another.

The World Wide Web was founded on standards, very loose ones to be sure. 
The old WWW philosophy encourages innovation and experimentation by 
ensuring that many different standards can coexist happily, simply by 
declaring what standard they support publicly. But if you say you support a 
MIME type then you ought to do it. Period. People will laugh at you 
otherwise. But that naif early viewpoint is about as antiquated as 
hand-tooled leather buggy whips in a commercial world.

We can't afford to support or develop to secret or proprietary standards, 
such as currently exist in all the major browsers. Individual designers who 
study the tricks of the trade may profit from this lack of standards, but 
at the expense of their customers, who have to pay dearly for their 
expertise. Individual companies, especially those with monopoly dominance 
of the market, may profit from selling figurative razors that fit only 
their own razor blades, but at the expense of their customers, who may well 
resent it. The "spin" from marketeers is that "innovation" in standards is 
a *good* thing, but try selling an "innovative" bolt size to anyone in the 
world except, as mentioned before, a nut.

The only reason these elitist differences exist is that the Web hasn't been 
really important until now. But that's changing. Just as you can swipe your 
credit card through any card reader in the world, because inter-operability 
is *very* important to people who deal in *real* money, the Web is going to 
become standardized whether we like it or not.

Lee Anne Phillips

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



From rev-bob at gotc.com  Mon Nov  8 22:58:37 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:41 2004
Subject: Why do we write standards?
Message-ID: <199911081758336.SM00211@Unknown.>

Perhaps I'm coming at this from a different angle than you are, but in the current context 
(Web development and standards), I must disagree with just about everything you say 
here.  Specifically:

> When you standardize, the benefits that you hope to achieve stem
> mainly from the network effect -- lower development costs and greater
> interoperability spring immediately to mind.  These benefits are so
> powerful (and so tempting) that they often lead people to rush to
> standardization.

The Web is supposedly all about interoperability and platform independence.  For either 
of these to be possible, we have to have some way to ensure the following:

1. Web authors must be able to develop pages with some expectation that they can be 
read...no matter what UA a given visitor is using.  The number of UAs and platforms is 
already so diverse that "test the page on everything" is impossible for the average author.
2. UA authors must be able to develop UAs with some expectation that they will 
properly interpret Web pages...no matter what site a given user visits.  The number of 
web pages is up in the millions; "test the UA on everything" is flat-out impossible.

By setting a standard, both sides (theoretically) gain a huge advantage, and thus the third 
side of the discussion - Joe Average, who uses a UA to visit pages - sees a benefit right 
along with 'em.  Web authors can code to the standard, UA authors can code to the 
standard, and Joe Average can use a standard-compliant UA to visit standard-compliant 
pages and see them at least roughly as intended.  That's the goal, right?

The problem comes in when we see incomplete standards, incomplete implementations, 
crude authoring hacks, and old UAs.  For a prime example, take what I was working on 
this weekend and some of last week.  Way back in the HTML 3.0 proposal, a tag named 
Q came along, to demarcate inline quotations.  Q got accepted into the 3.2 spec, and 
carried over into 4.0.  Fine and dandy.  From a rendering viewpoint, Q is extremely 
simple to handle except where the CITE attribute is concerned: put quotes around the 
contents, alternating as needed when one Q tag is nested inside another.  Considering 
how long this tag's been in the specs, this should be almost universal by now, right?  
Wrong; the only currently-available browser I can find which handles Q properly is 
Lynx, starting with version 2.6.  Netscape and Microsoft have both utterly ignored this 
part of the specs, making them noncompliant.  (To be fair, the Gecko build I have 
correctly handles Q - but as Gecko is still pre-alpha, I can't really count that.)

> On the other hand, standardization has many costs, of which the most
> obvious are the initial cost of implementing more than you need to
> (since standards are necessarily a superset of the needs of any
> specific set of users) and the risk of committing to an inappropriate
> solution prematurely and squashing real innovation.

And here I thought the whole reason for a standards ratification process and a 
Consortium to oversee it was to address exactly those points.  By the time a specification 
gets to the status of a Recommendation, it has been hashed over much more thoroughly 
than most federal laws; we can hardly consider this result a rash, premature conclusion.

> If a standard is successful, the network effect can more than
> compensate for the negatives, but most standards simply fail and leave
> the early implementors out of pocket.  The problem is that,
> traditionally, standardization has solved existing problems: everyone
> had trains but they could not run on the same rail gauge, or there
> were many different phone companies but customers from one could not
> call customers from another another, or every public house used a
> different sized glass so it wasn't possible to compare prices.

And now, everyone has a browser but they can't view the same Web pages.  To return 
to that Q concern, I can solve it with some relatively easy server-side logic - but 
compared to Joe Average Author, I'm the exception.  Most authors don't have that tool 
available, and many of those who do aren't willing to expend a great deal of effort in 
tuning the code that closely.  ("Serve a quotation mark entity to everybody except Lynx 
and Gecko users, and serve the Q tags to everybody except old browsers - does that 
work?"  Yeah, that work...too *much* work.)

> Now that we're trying to standardize in *advance* of implementation,
> we run an enormous risk of messing up: our industry simply lacks any
> real, large-scale implementation experience to guide the process, so
> we're just publishing our own wild speculations and stamping them as
> W3C Recommendations or ISO standards or what-have-you.

Hey, we've seen the damage done by leaving innovation in the hands of the browser 
authors - the Web still hasn't recovered from that fragmenting, and the current state of 
affairs is at least partly due to people like myself crying out "Enough!"

> The solution is to standardize incrementally to minimize the risks,
> and to concentrate initially on the areas that will bring the most
> benefit for the least effort.

Keep in mind that once a UA is released, it never goes away - and people like me who 
actually want to communicate instead of just writing "k00l pagezzzz" will have to keep 
developing pages to accomodate it.  "Fix it in the next release" may work inside a 
company, but the general public is justifiably sick of it.  Witness the general public's sour 
reaction to Microsoft's "fix it next time out" attitude with Windows....



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 23:01:55 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:41 2004
Subject: Why do we write standards?
References: <003901bf271e$fe5a5be0$099918d1@docuverse1>
	 <3822FC81.D077B6F7@prescod.net> <m3iu3givwn.fsf@localhost.localdomain>
	 <3825E52F.31E71581@prescod.net> <m33duhcszh.fsf_-_@localhost.localdomain>
Message-ID: <38275646.4727BC3D@pacbell.net>

David Megginson wrote:
> 
> That's a fair question.  The short answer is that I disagree with your
> opinion -- standardization is a kind of regulation, and deciding when
> and how to regulate is a very difficult balancing act between benefits
> (the Socialist view) and costs (the Libertarian view).

Interesting ... but then there are more aspects to balance:

 
> Now that we're trying to standardize in *advance* of implementation,

Why?  The "we" that tries to standardize way early isn't the XML-DEV sort
of crowd, but more of a corporate crowd anticipating either (a) time to
market advantage, or (b) industry power supported by such standards, or
surely similar things that I'm less conscious of.

That's a "benefits" case that's not Socialist, since the benefits are
intended to be optimized for only a few folk (one vendor, or maybe a
consortium).  Call it capitalist; sometimes even monopolist.


> The solution is to standardize incrementally to minimize the risks,
> and to concentrate initially on the areas that will bring the most
> benefit for the least effort.

I like incremental work, but "least" effort isn't the only concern
there too.  Consider an organization that really can't commit any
energy in an area unless it's applying, say, twenty engineers.

Such an organization will see "least effort" and "incremental" and
especially "benefit" rather differently from any individual, who
will normally think in terms of part time effort ... that's two whole
orders of magnitude difference, and that changes folks' perspectives
in major ways.

I'm not saying that's any sort of globally (or even locally) optimal
way to answer the question, but it's a widely adopted answer that
doesn't seem to fit into a socialist-v-libertarian dimension.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  8 23:56:27 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:41 2004
Subject: XHTML 1.0 returned to HTML WG
Message-ID: <000001bf2a45$1dadc260$099918d1@docuverse1>

Paul,

I think we should wrap up this thread here (with a Duck Tape :).

<IMHO>
There is zero chance of the three line spec happening whether it
makes sense or not.  There is also zero chance of us convincing
each other one way another.  It would have been a nice continuing
conversation piece over drinks but I can't send liquior through
XML-DEV's attachment restrictions.  Oh, well.
</IMHO>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From duvall at lorien.emufarm.org  Tue Nov  9 07:13:12 1999
From: duvall at lorien.emufarm.org (Danek Duvall)
Date: Mon Jun  7 17:16:42 2004
Subject: `server parsed' XML?
Message-ID: <19991108231247.A13739@lorien.emufarm.org>

I see that a similar question has been asked here before, but I haven't
found an answer that will satisfy my requirements.  So I'll try to be as
specific as possible.

What I want is to have a static xml file lying around, that has some sort
of token in it that represents, say, the current date.  In my program, as I
parse the xml file, I want to dynamically change that token into a string
representing the date.

That is, say I have a file foo.xml that contains in it:

   blah, blah, blah &date; blah, blah, blah

When I read it in on November 15, 1999, I want to get back

   blah, blah, blah November 15, 1999 blah, blah, blah

I don't care that the token be &date; ; I just have to be able to say where
the replaced tokens go.

How can I do this, if at all, with SAX 1.0 and DOM 1.0 routines,
specifically as implemented in Sun's Project-X (TR-2) parser?

Thanks very much,
Danek

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 08:16:06 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:42 2004
Subject: `server parsed' XML?
References: <19991108231247.A13739@lorien.emufarm.org>
Message-ID: <3827D840.6F9318B6@pacbell.net>

> That is, say I have a file foo.xml that contains in it:
> 
>    blah, blah, blah &date; blah, blah, blah
> 
> When I read it in on November 15, 1999, I want to get back
> 
>    blah, blah, blah November 15, 1999 blah, blah, blah
> 
> I don't care that the token be &date; ; I just have to be able to say where
> the replaced tokens go.
> 
> How can I do this, if at all, with SAX 1.0 and DOM 1.0 routines,
> specifically as implemented in Sun's Project-X (TR-2) parser?

Two ways come quickly to mind:

(1) <!ENTITY date SYSTEM "http://dateserver/servlet/getdate">

	... and a servlet (or cgi or whatever) that expands
	appropriately.  Assumes a webserver is available,
	but works with any (!) XML parser.

(2) <?builtin-date?>

	... with some processing componenent that knows how
	to expand the 'builtin-date' PI.  Assumes you provide
	custom application code to handle this.

There's the suggestion in the XML spec that (2) be independant of
the actual PI name, perhaps

	<!NOTATION builtin-date SYSTEM "urn:something-built-in">

and the processor keying on that SYSTEM id, so that "builtin-date"
could be anything.  Of course, never build in anything as insecure
as an arbitrary shell escape; and have the processing component
that interprets those PIs generate no output except for a PI that's
inside the root element.

I'd likely use #2, as it's lower overhead.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From blee at daou.co.kr  Tue Nov  9 08:38:41 1999
From: blee at daou.co.kr (blee@daou.co.kr)
Date: Mon Jun  7 17:16:42 2004
Subject: unsubscribe
References: <19991108231247.A13739@lorien.emufarm.org> <3827D840.6F9318B6@pacbell.net>
Message-ID: <3827DD2D.13A1E141@daou.co.kr>




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



From rgl at decisionsoft.com  Tue Nov  9 10:00:22 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:16:42 2004
Subject: `server parsed' XML?
In-Reply-To: <19991108231247.A13739@lorien.emufarm.org>
Message-ID: <Pine.LNX.4.10.9911090953210.2176-100000@localhost.localdomain>

On Mon, 8 Nov 1999, Danek Duvall wrote:

> What I want is to have a static xml file lying around, that has some sort
> of token in it that represents, say, the current date.  In my program, as I
> parse the xml file, I want to dynamically change that token into a string
> representing the date.
> 
> That is, say I have a file foo.xml that contains in it:
> 
>    blah, blah, blah &date; blah, blah, blah
> 
> When I read it in on November 15, 1999, I want to get back
> 
>    blah, blah, blah November 15, 1999 blah, blah, blah

This is more or less how "interpolations" work in XML Script
(www.xmlscript.org), although in this case you'd write:

blah, blah, blah #time()# blah, blah, blah

Then when this is processed by an XML Script processor everything between
the hashes (in this case, the time() built-in command) is evaluated.

Actually, time() gives UTC time, which probably isn't what you want, but
you could replace it with date_str("%d-%m-%Y",time()) or something
similar.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


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



From rev-bob at gotc.com  Tue Nov  9 11:30:29 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:42 2004
Subject: `server parsed' XML?
Message-ID: <199911090630645.SM00172@Unknown.>

> > What I want is to have a static xml file lying around, that has some sort
> > of token in it that represents, say, the current date.  In my program, as I
> > parse the xml file, I want to dynamically change that token into a string
> > representing the date.
> > 
> > That is, say I have a file foo.xml that contains in it:
> > 
> >    blah, blah, blah &date; blah, blah, blah
> > 
> > When I read it in on November 15, 1999, I want to get back
> > 
> >    blah, blah, blah November 15, 1999 blah, blah, blah
> 
> This is more or less how "interpolations" work in XML Script
> (www.xmlscript.org), although in this case you'd write:
> 
> blah, blah, blah #time()# blah, blah, blah
> 
> Then when this is processed by an XML Script processor everything between
> the hashes (in this case, the time() built-in command) is evaluated.

Here's another option, depending on what you have available to you.  I've had wonderful 
success using Inline's iHTML software (see their site at http://www.ihtml.com) to make 
a given document morph on the fly - and contrary to the name's implications, this will 
work just fine on XML documents if you configure it to do so.  (For instance, see 
http://www.gotc.com/index.xml - when you look at the source, you should see a few 
examples of dynamic processing at work.  Among the most obvious are that the slogan 
under the logo, the background image, the fake ad at the bottom of the page, and the 
warning/note just above the navigation bar are all set randomly from a list of options in a 
database - no client-side scripting required.  There's also a JavaScript routine that looks 
fairly pointless - fancy() is set up to simply return one number, with no indication of how 
that number was calculated.  Naturally, it was done on the server.)

I should note a few things at this point.  First, that GOTC page is still a work-in-progress, 
and if anyone has trouble seeing it with a functional XML browser, I'd like to know 
about it before I make that part of the site live.  Second, iHTML can be fairly expensive 
for an individual user, but once you get to a company level, that's not so bad.  (I'm lucky 
enough to use an ISP that has the Enterprise edition installed.)  Finally, iHTML code 
does not look well-formed; while this is not a functional problem, odds are it'll give a 
validation tool fits if you run the tool on the raw code instead of on what you get if you 
actually have iHTML parse the code first.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jamesr at steptwo.com.au  Tue Nov  9 12:44:00 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:16:42 2004
Subject: `server parsed' XML?
In-Reply-To: <Pine.LNX.4.10.9911090953210.2176-100000@localhost.localdom
 ain>
References: <19991108231247.A13739@lorien.emufarm.org>
Message-ID: <4.2.0.58.19991109233723.00c9a1b0@203.41.126.17>


>On Mon, 8 Nov 1999, Danek Duvall wrote:
>
> > What I want is to have a static xml file lying around, that has some sort
> > of token in it that represents, say, the current date.  In my program, as I
> > parse the xml file, I want to dynamically change that token into a string
> > representing the date.
> >
> > That is, say I have a file foo.xml that contains in it:
> >
> >    blah, blah, blah &date; blah, blah, blah
> >
> > When I read it in on November 15, 1999, I want to get back
> >
> >    blah, blah, blah November 15, 1999 blah, blah, blah

Have you considered pre-processing
the file using a standard text manipulation
tool?

AWK/Perl/Python spring to mind.
You could also do it with Omnimark.

(In Omnimark you would use the rule:

FIND "&date;"
         OUTPUT DATE
)

I'm a great believer in bolting together
the necessary tools in sequence to solve problems,
rather than using the one tool for everything.

And this is really a flat-file problem, not
an XML problem.

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  9 13:41:20 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:16:42 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <199911052037.VAA02691@chimay.loria.fr>
 <3824E917.78555C71@isogen.com> <199911071821.MAA03281@bruno.techno.com>
Message-ID: <3826E29D.6BAFF240@isogen.com>

"Steven R. Newcomb" wrote:
> 
> [Eliot Kimber:]
> 
> > [...snip...] external parsed entities ("external text entities" in
> > SGML parlance) are evil and should never have been included in XML.

[...]

> The trick is for people to realize that the use of parsed external
> entities should be avoided unless their use is purely for storage
> convenience.  There should never be a semantic load on the fact that
> some data is stored in a particular entity.  Regrettably, most of the
> times when parsed external entities have been used, they have been
> used for impure, semantically loaded purposes (such as the semantic of
> re-usability).  So maybe as a matter of good public education policy,
> Eliot's position that "external parsed entities are evil" is the right
> approach, as long as we're not going to get rid of XML's ability to
> support them.

The reason I think that external parsed entities are evil is precisely
because they encourage people to do this stupid thing *which is almost
never the right thing to do*. People innocently and understandably use
them to solve immediate practical problems, encouraged by tools that
support only this form of data organization (at least out of the
box--most, if not all, can be taught to do the right thing), only to
wake up one day and discover they have an unworkable system that will
now require huge effort to rework to meet their requirements.  To my
mind, this is the same sort of evil as Microsoft Word: an immdiately
convenient and apparently useful facility that is available everywhere
that you can use without thinking, only to realize later that you're
screwed eight ways from Sunday for having used it without thinking about
it carefully first.

Or maybe it needs to be a social presure thing: "friends don't let
friends use external parsed entities for re-use."

The *ONLY TIME* external parsed entities are the right thing to do is
when exactly one actor is working on exactly one doucment and needs to
partition it into separate files for *their own* convenience. *AT ALL
OTHER TIMES* external parsed entities are not the right thing to use.

I think it would have been much better to force all non-trivial XML
applications to step up to the reality that almost all documents are
compound documents semantically (but not syntactically) composed of
separate XML documents. If SGML or XML had done this, we wouldn't be
having this discussion now because the problem wouldn't arise.

Note that there is the inverse requirement as well: the need to
*syntactically combine* structures that are *semantically* separate
documents. This is the problem that name spaces try to solve (but fail
to solve, for reasons that should be obvious and that I will not repeat
having expounded on them at length in the past). The solution has often
be characterized as "inline subdocs". I am convinced that without this
feature, XML and SGML are inherently limited in a serious way (as
evidenced by the sadly misguided excitement over name spaces, which
demonstrates a serious unmet requirement). [Fortunately, the
infrastructure you need to have in place to do re-use can also support
this form of document, so we can survive without this feature although
the solution is suboptimal and not very satisfying.]

Essentially, we need to have a markup and processing infrastructure that
decouples the storage structure of documents from their logical
structure so that we can have it both ways: one storage object with
multiple documents or one document distributed across multiple storage
objects, as well as true reusability.

Lest people think that I'm just talking: I have contributed to the
development of a very large scale SGML/XML-based system now in
production that is entirely based on the non-use of external parsed
entities. I am currently helping to implement another such system for
the State of Texas. Everything you need can be done with existing tools
and technology with very little extra effort *if you do it up front*.

My take is that there is no excuse for not doing it right. It's not like
the tool developers don't understand the issue nor are they unware of
the existing standards and implementing technology (I know because I've
talked to all the editor and database vendors personally at some length
about this).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 13:39:54 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:42 2004
Subject: Why do we write standards?
In-Reply-To: <m33duhcszh.fsf_-_@localhost.localdomain>
References: <Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600">
 <003901bf271e$fe5a5be0$099918d1@docuverse1>
 <3822FC81.D077B6F7@prescod.net>
 <m3iu3givwn.fsf@localhost.localdomain>
 <3825E52F.31E71581@prescod.net>
Message-ID: <199911091339.IAA01153@hesketh.net>

At 03:01 AM 11/8/99 -0500, David Megginson wrote:
>When you standardize, the benefits that you hope to achieve stem
>mainly from the network effect -- lower development costs and greater
>interoperability spring immediately to mind.  These benefits are so
>powerful (and so tempting) that they often lead people to rush to
>standardization.
>
>On the other hand, standardization has many costs, of which the most
>obvious are the initial cost of implementing more than you need to
>(since standards are necessarily a superset of the needs of any
>specific set of users) and the risk of committing to an inappropriate
>solution prematurely and squashing real innovation.

I'm not opposed to standards development, but I think David is very right
to question the 'rush to standards' that seems to have infected the XML world.

I've written on this previously
(http://www.simonstl.com/articles/doubting.htm) and will be writing on it a
lot more to come, but I'm deeply disturbed by how many people seem to think
that creating standards is the end-all and be-all of XML.

It's not just about 'proprietary' vs. 'open' - in large part, I'm concerned
that there are enormous costs involved where standardization takes place
before the relationships and information involved are actually sorted out
in practice.  Modeling relationships is especially complicated when the
relationships themselves aren't genuinely standardized.  (Indeed, it's easy
to question what portion of these relationships should be standardized.)

XML itself took a brilliant (though somewhat compromised) approach -
defining a minimum set of tools that could be used by the widest range of
users. That foundation - elements and attributes - provides much more
powerful and flexible structures than was readily available before.

We've got the core set.  Why not let users experiment with that basic set
of tools before we try to slap them in straitjackets?  I hear people on
this list insisting on the need for constraints, for fixed structures, for
all that stuff that made sense when computers were (relatively) slow and
stupid and data structures were hard to convert from one form to another.  

I'd love to leave that baggage behind and recognize that we might have
something genuinely new in XML, a flexible toolkit that can break the rules
we've grown accustomed to over the last fifty years of computing. XML can
break new ground between the formal structures computers are best at and
the more natural structures that reflect how people communicate with each
other, not with machines.

It may not seem realistic to the usual gang of IT people, but I'd like to
see this more flexible approach given a chance before we suffocate it with
experts running around developing standards.  Let local organizations
figure out the tactics before larger organizations create strategies that
may or may not work.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From vlashua at RSGsystems.com  Tue Nov  9 13:57:24 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:42 2004
Subject: `server parsed' XML?
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CA2@MAILPROD>

Or put a javascript module in an XML tag that is embedded in the "main
document"? Some process will have to process the token, regardless.
Vane
-----Original Message-----
From: James Robertson [mailto:jamesr@steptwo.com.au]
Sent: Tuesday, November 09, 1999 7:40 AM
To: xml-dev@ic.ac.uk
Subject: Re: `server parsed' XML?



>On Mon, 8 Nov 1999, Danek Duvall wrote:
>
> > What I want is to have a static xml file lying around, that has some
sort
> > of token in it that represents, say, the current date.  In my program,
as I
> > parse the xml file, I want to dynamically change that token into a
string
> > representing the date.
> >
> > That is, say I have a file foo.xml that contains in it:
> >
> >    blah, blah, blah &date; blah, blah, blah
> >
> > When I read it in on November 15, 1999, I want to get back
> >
> >    blah, blah, blah November 15, 1999 blah, blah, blah

Have you considered pre-processing
the file using a standard text manipulation
tool?

AWK/Perl/Python spring to mind.
You could also do it with Omnimark.

(In Omnimark you would use the rule:

FIND "&date;"
         OUTPUT DATE
)

I'm a great believer in bolting together
the necessary tools in sequence to solve problems,
rather than using the one tool for everything.

And this is really a flat-file problem, not
an XML problem.

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 14:19:53 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:16:42 2004
Subject: Why do we write standards?
References: <Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600"><003901bf271e$fe5a5be0$099918d1@docuverse1><3822FC81.D077B6F7@prescod.net><m3iu3givwn.fsf@localhost.localdomain><3825E52F.31E71581@prescod.net> <199911091339.IAA01153@hesketh.net>
Message-ID: <03a501bf2abd$fee46630$1918ccce@murphy>

>>Why not let users experiment with that basic set of tools before we try to
slap them in straitjackets?

It's happening my man.

Tim Bray came for a visit a couple of weeks ago. In the car, on the way to
lunch, I told him that the XML 1.0 spec was working great for us. A few days
before a question had come up on the XML-RPC list, and I didn't know the
answer. I went to the spec, and it had the answer! That's a work that works,
imho.

Who knows, maybe two years from now we'll be looking for an answer and it
will be in the Schema spec or whatever you guys are working on now. I'll
tell you this much, at a practical level, in the real-world, XML is taking
off. It's really happening.

BTW, I have a master's in computer science, and a math degree in graph
theory, so I know at a theoretic level, what all this stuff is about. But 20
years ago I decided to be a commercial developer, and not a theorist. So I
focus entirely on the pragmatic side of these things. My take is that XML
1.0 is ready to go, it's happening in syndication/aggregation and
distributed computing protocols.

One man's opinion only..

Dave

PS: One thing that's really needed is a *simple* spec for vector graphics.
Not PDF-in-XML, just lineto, moveto, fillrect, drawstring, invertrect,
penup, pendown, etc. Refer to Inside Macintosh v1.0, QuickDraw chapter.
Another spec that really worked.


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



From vlashua at RSGsystems.com  Tue Nov  9 15:40:32 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:42 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CA5@MAILPROD>

... and what, master [no cynicism implied], is the mechanism you have come
up with for Texans?
Vane
-----Original Message-----
From: W. Eliot Kimber [mailto:eliot@isogen.com]
Sent: Monday, November 08, 1999 9:48 AM
To: xml-dev@ic.ac.uk
Subject: Re: external parsed entites (was: A unique ID question ?)


"Steven R. Newcomb" wrote:
> 
> [Eliot Kimber:]
> 
> > [...snip...] external parsed entities ("external text entities" in
> > SGML parlance) are evil and should never have been included in XML.

[...]

> The trick is for people to realize that the use of parsed external
> entities should be avoided unless their use is purely for storage
> convenience.  There should never be a semantic load on the fact that
> some data is stored in a particular entity.  Regrettably, most of the
> times when parsed external entities have been used, they have been
> used for impure, semantically loaded purposes (such as the semantic of
> re-usability).  So maybe as a matter of good public education policy,
> Eliot's position that "external parsed entities are evil" is the right
> approach, as long as we're not going to get rid of XML's ability to
> support them.

The reason I think that external parsed entities are evil is precisely
because they encourage people to do this stupid thing *which is almost
never the right thing to do*. People innocently and understandably use
them to solve immediate practical problems, encouraged by tools that
support only this form of data organization (at least out of the
box--most, if not all, can be taught to do the right thing), only to
wake up one day and discover they have an unworkable system that will
now require huge effort to rework to meet their requirements.  To my
mind, this is the same sort of evil as Microsoft Word: an immdiately
convenient and apparently useful facility that is available everywhere
that you can use without thinking, only to realize later that you're
screwed eight ways from Sunday for having used it without thinking about
it carefully first.

Or maybe it needs to be a social presure thing: "friends don't let
friends use external parsed entities for re-use."

The *ONLY TIME* external parsed entities are the right thing to do is
when exactly one actor is working on exactly one doucment and needs to
partition it into separate files for *their own* convenience. *AT ALL
OTHER TIMES* external parsed entities are not the right thing to use.

I think it would have been much better to force all non-trivial XML
applications to step up to the reality that almost all documents are
compound documents semantically (but not syntactically) composed of
separate XML documents. If SGML or XML had done this, we wouldn't be
having this discussion now because the problem wouldn't arise.

Note that there is the inverse requirement as well: the need to
*syntactically combine* structures that are *semantically* separate
documents. This is the problem that name spaces try to solve (but fail
to solve, for reasons that should be obvious and that I will not repeat
having expounded on them at length in the past). The solution has often
be characterized as "inline subdocs". I am convinced that without this
feature, XML and SGML are inherently limited in a serious way (as
evidenced by the sadly misguided excitement over name spaces, which
demonstrates a serious unmet requirement). [Fortunately, the
infrastructure you need to have in place to do re-use can also support
this form of document, so we can survive without this feature although
the solution is suboptimal and not very satisfying.]

Essentially, we need to have a markup and processing infrastructure that
decouples the storage structure of documents from their logical
structure so that we can have it both ways: one storage object with
multiple documents or one document distributed across multiple storage
objects, as well as true reusability.

Lest people think that I'm just talking: I have contributed to the
development of a very large scale SGML/XML-based system now in
production that is entirely based on the non-use of external parsed
entities. I am currently helping to implement another such system for
the State of Texas. Everything you need can be done with existing tools
and technology with very little extra effort *if you do it up front*.

My take is that there is no excuse for not doing it right. It's not like
the tool developers don't understand the issue nor are they unware of
the existing standards and implementing technology (I know because I've
talked to all the editor and database vendors personally at some length
about this).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dhunter at Mobility.com  Tue Nov  9 16:55:47 1999
From: dhunter at Mobility.com (Hunter, David)
Date: Mon Jun  7 17:16:42 2004
Subject: Why do we write standards?
Message-ID: <805C62F55FFAD1118D0800805FBB428D02BC008F@cc20exch2.mobility.com>

From: David Megginson [mailto:david@megginson.com]
Sent: Monday, November 08, 1999 3:01 AM

> On the other hand, standardization has many costs, of which the most
> obvious are the initial cost of implementing more than you need to
> (since standards are necessarily a superset of the needs of any
> specific set of users) and the risk of committing to an inappropriate
> solution prematurely and squashing real innovation.

On the other hand, if we look at the whole picture, we're not looking at *a*
standard - we're looking at a *group* of related standards, which all
contribute to one "overall vision" - XML, [XHTML,] Namespaces, Schema,
XPath, XSL, XLink/XPointer, and a plethora of other standards we're all
aware of.  Obviously nobody is saying that if you write an application that
uses XML you have to implement *all* of these standards.  Just the ones you
need.  So I don't think the cost of implementing more than you need is too
great.

> Now that we're trying to standardize in *advance* of implementation,
> we run an enormous risk of messing up: our industry simply lacks any
> real, large-scale implementation experience to guide the process, so
> we're just publishing our own wild speculations and stamping them as
> W3C Recommendations or ISO standards or what-have-you.

Standardizing the grammar of XHTML isn't the hard part, imHo, because we've
already been doing it for years with HTML.  All the XHTML people have to do,
in this regard, is say "here is what we've learned from HTML, let's XML-ize
it, and standardize it, so that any XHTML document can be shown in any
XHTML-compliant browser."  (I know, I know, I say "ALL they have to do" as
if it's easy...)  This isn't standardization in advance of implementation,
this is standardization in retrospective.

The *new* part is somehow managing to combine XHTML documents with other XML
documents.  This is the part that could be considered standardization in
advance of implementation.  So if people say <overstatement?>"let's just say
the XHTML namespace is 'blah', do what you want with the grammar and we'll
standardize it later [maybe]"</overstatement?>, that seems completely
backwards to me.  And actually starts us off worse than when HTML was first
developed.  At least then there was some kind of a spec, and the browser
writers just did whatever they felt like with it; but now we're not even
giving them a spec(!).  Just "Okay, do whatever you want, cowboys!"  So
what's going to happen?  Anything a browser writer puts into the browser
that doesn't make it into the eventual XHTML spec will have to *stay* in
that browser, in case there are documents out there that use that feature.
Which is exactly what goes on today.  In a few years time, I don't want to
have to be thinking things like "Okay, if I use this tag I'll have to hack
around this other feature, because the version 8 browser implemented this
differently..."

David Hunter
david.hunter@mobileq.com
http://www.MobileQ.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 17:10:19 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:16:42 2004
Subject: dtddiff of XSDL November and September drafts
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F2780CB@MDYNYCMSX1>

Below is the output of Earl Hood's dtddiff utility (see
http://www.oac.uci.edu/indiv/ehood/perlSGML.html for his collection of
perlSGML utilities) when comparing the DTD from the November 5th draft of
the W3C XML Schema proposal with the one from the September 24th version.
The two-column arrangement is easier to read in monospaced type. Note that
content model differences are highlighted by the use of all caps for the
changed parts. 

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii


    ----------------------------------------------------------------------
                 New Elements/Attributes (xmlschema11-99.dtd)
    ----------------------------------------------------------------------
	<export groups>                  <group export>
	<group ref>                      <group schemaabbrev>
	<group schemaname>               <import groups>
	<include groups>                 <pattern>
	<period>
    ----------------------------------------------------------------------
             Old/removed Elements/Attributes (xmlschema9-99.dtd)
    ----------------------------------------------------------------------
	<export modelgroups>             <import modelgroups>
	<include modelgroups>            <lexicalrepresentation>
	<modelgroup>                     <modelgroup export>
	<modelgroup name>                <modelgroup order>
	<modelgroupref>                  <modelgroupref maxoccurs>
	<modelgroupref minoccurs>        <modelgroupref name>
	<modelgroupref schemaabbrev>     <modelgroupref schemaname>
    ----------------------------------------------------------------------
                           Content Rule Differences
    ----------------------------------------------------------------------
         ------------------------------------------------------------
	                         <ARCHETYPE>

  << old content rule <<
  (refines*,
   ((element|group|MODELGROUPREF)*|datatypequal?),
   (attribute|attrgroupref)*)

  >> new content rule >>
  (refines*,
   ((element|group)*|datatypequal?),
   (attribute|attrgroupref)*)

         ------------------------------------------------------------
	                         <ATTRIBUTE>

  << old content rule <<
  ((mininclusive|minexclusive)|
   (maxinclusive|maxexclusive)|
   (maxabsolutevalue,minabsolutevalue)?|precision|scale|
   LEXICALREPRESENTATION|enumeration|length|maxlength|encoding)*

  >> new content rule >>
  ((mininclusive|minexclusive)|
   (maxinclusive|maxexclusive)|
   (maxabsolutevalue,minabsolutevalue)?|precision|scale|pattern|
   enumeration|length|maxlength|encoding|period)*

         ------------------------------------------------------------
	                          <DATATYPE>

  << old content rule <<
  (basetype,
   ((mininclusive|minexclusive)|
    (maxinclusive|maxexclusive)|
    (maxabsolutevalue,minabsolutevalue)?|precision|scale|
    LEXICALREPRESENTATION|enumeration|length|maxlength|encoding)*)

  >> new content rule >>
  (basetype,
   ((mininclusive|minexclusive)|
    (maxinclusive|maxexclusive)|
    (maxabsolutevalue,minabsolutevalue)?|precision|scale|pattern|
    enumeration|length|maxlength|encoding|period)*)

         ------------------------------------------------------------
	                        <DATATYPEQUAL>

  << old content rule <<
  ((mininclusive|minexclusive)|
   (maxinclusive|maxexclusive)|
   (maxabsolutevalue,minabsolutevalue)?|precision|scale|
   LEXICALREPRESENTATION|enumeration|length|maxlength|encoding)*

  >> new content rule >>
  ((mininclusive|minexclusive)|
   (maxinclusive|maxexclusive)|
   (maxabsolutevalue,minabsolutevalue)?|precision|scale|pattern|
   enumeration|length|maxlength|encoding|period)*

         ------------------------------------------------------------
	                           <GROUP>

  << old content rule <<
  (element|group|MODELGROUPREF)+

  >> new content rule >>
  (element|group)*

         ------------------------------------------------------------
	                           <SCHEMA>

  << old content rule <<
  ((import*,include*,export?,
    (comment|datatype|archetype|element|attrgroup|MODELGROUP|notation|
     textentity|externalentity|unparsedentity)*))

  >> new content rule >>
  ((import*,include*,export?,
    (comment|datatype|archetype|element|attrgroup|group|notation|
     textentity|externalentity|unparsedentity)*))


















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



From ht at cogsci.ed.ac.uk  Tue Nov  9 17:34:28 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:16:42 2004
Subject: dtddiff of XSDL November and September drafts
In-Reply-To: "DuCharme, Robert"'s message of "Tue, 9 Nov 1999 12:10:55 -0500"
References: <01BA10F0CD20D3119B2400805FD40F9F2780CB@MDYNYCMSX1>
Message-ID: <f5bk8nrvabc.fsf@cogsci.ed.ac.uk>

The conclusion you might draw from the DTD differences Bob posted
(thanks!) is that there is not much changed between the September and
November drafts.

Speaking unofficially, you would not be wrong in making that
assumption.

The next draft will be a much bigger step (forward, we hope :-)

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From xml at searchtools.com  Tue Nov  9 17:44:59 1999
From: xml at searchtools.com (Avi Rappoport)
Date: Mon Jun  7 17:16:42 2004
Subject: Apache To Take On XML Efforts
In-Reply-To: 
 <805C62F55FFAD1118D0800805FBB428D02BC008F@cc20exch2.mobility.com>
References: 
 <805C62F55FFAD1118D0800805FBB428D02BC008F@cc20exch2.mobility.com>
Message-ID: <v04220806b44e0a875add@[171.66.196.146]>

This came in the InternetWorld Newsletter this morning, the site is 
supposed to be <http://www.internetworldnews.com> but it's down, so 
I'll extract useful bits.  The other useful URL seems to be 
<http://xml.apache.org>

----------------
Apache To Take On XML Efforts
By Nate Zelnick

[commentary on XML's lack of Java-like hype snipped]

.... IBM ( http://www.ibm.com )and  Sun Microsystems ( http://www.sun.com )
... will announce Tuesday that they are turning over source code for
their respective XML parsing engines to the Apache Software
Foundation ( http://www.apache.org )...

...

Apache plans to build developer tools that make the adoption
of XML an easier process for information architects, Web
designers, and application providers. This, it is hoped, will
light a fire under the industry's currently sluggish movements
toward adopting a universal standard for describing structured
documents.

In addition to IBM and Sun, DataChannel
( http://www.datachannel.com ), Lotus Development
Corp., and a host of other XML-oriented companies that
aren't Microsoft are also expected to contribute technology
to the Apache effort. Microsoft may participate in future
open source XML efforts with Apache, according to a spokesperson.
Information about Apache's XML efforts will be available
at <http://xml.apache.org>.

--------------

Interesting stuff.

Avi
_______________________________________________________
Guide to Local Site, Intranet, and Portal Search Engines: 
<http://www.searchtools.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 18:00:49 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:42 2004
Subject: Why do we write standards?
References: <Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600">
 <003901bf271e$fe5a5be0$099918d1@docuverse1>
 <3822FC81.D077B6F7@prescod.net>
 <m3iu3givwn.fsf@localhost.localdomain>
 <3825E52F.31E71581@prescod.net> <199911091339.IAA01153@hesketh.net>
Message-ID: <199911091754.LAA04564@bruno.techno.com>


Why do I help to create standards?  Because the alternative is to
place everyone's creative work in jeopardy, along with civilization's
memory in general.

I realize that this is just *my* reason and it doesn't have to be
everyone's reason.  I once used a proprietary language to represent my
interactive course in 16th-century counterpoint; it was never
published because Control Data Corporation capriciously and
unnecessarily changed the language.  Ever since then, I've been
working to prevent similar calamities by providing standards that
don't change at the whim of some (consortium of) private interest(s).
The bad guy for me was Control Data Corporation, but it could have
been any technology company.  We shouldn't expect information
technology companies to be responsive to the need of future
generations to exploit today's information assets, and the creative
output of today's artists, scientists, and engineers.  Corporations
have no compelling reason to see that far ahead, and most large
organizations are insufficiently self-aware to learn from their
mistakes anyway.  But somebody needs to pay attention to the problem
of corporate memory at all scales.  I'm just one of the people who are
paying attention, and my way of paying attention is to seek standard
ways of doing things that will make information robust enough to
survive for a very long time.

Why do I help to create ISO standards, as opposed to other kinds?

* Because I don't have access to other standards processes,

* Because ISO standards can't be changed unless it's in the public
  interest to change them, and

* Because ISO standards are at their best when they are even-handedly
  responsive to civilization-wide requirements, rather than merely the
  shorter-sighted desires of some particular industry or consortium.
  When working on ISO standards, I may not feel like I'm going to get
  rich, but I know that I'm working to make all of our descendants a
  lot richer.  Will ISO standards pay off in that way?  I don't know.
  I hope so.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  9 20:34:31 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun  7 17:16:43 2004
Subject: Schemas coming of age: use them
Message-ID: <011101bf2af1$79e15a40$e5061812@ridge.w3.org>

Agenda item for chairs meeting:

As I have mentioned in various fora including the AC meeting, xml schemas
are coming of age.  It is no longer appropriate for a W3C activity to say
"well, we won't use them because they aren't here yet". They are here --
there are drafts which you can read and use.

It is now appropriate for any group developing a W3C xml application (such
as P3P, xHTML, etc) to use namespaces and schemas.  These should be seen as
the first, very important, test cases for schema: if xml-schema language
won't do what you want it to do, then get it fixed.

Working across more groups takes time but it leads to a consistent result.
Let's  make sure everything fits together at this stage!

Keep up the good work, everyone.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 21:21:55 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:43 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <199911052037.VAA02691@chimay.loria.fr>
	 <3824E917.78555C71@isogen.com> <199911071821.MAA03281@bruno.techno.com> <3826E29D.6BAFF240@isogen.com>
Message-ID: <3828904C.50A80CEF@pacbell.net>

> ... external parsed entities are evil ...

Bringing morality into it seems ... irrelevant, extremist.

So far the reasons I've heard offered against using such
entities (general entities, not parameter entities):

  - Some tools don't handle big documents, and
    such entities let you construct big documents.

  - Some developers misinterpret the storage issue
    (external entity) as a semantic issue (reusable).

  - Gotta watch out for ID usage, since validity
    then requires cross-file consistency.

Or in short, the tool can be misused, so ban the tool.  I'm
not convinced, nor am I likely to be.  Applied with consistency,
that makes banging rocks together to make fire become evil.

For anyone collecting real issues to pay attention to when
using external parsed entities, you should add using relative
URIs in those entities.  Not all tools expose base URIs in a
way that lets you resolve the relative URIs correctly.  SAX
does (given a Locator).

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov  9 20:34:31 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun  7 17:16:43 2004
Subject: Schemas coming of age: use them
Message-ID: <011101bf2af1$79e15a40$e5061812@ridge.w3.org>

Agenda item for chairs meeting:

As I have mentioned in various fora including the AC meeting, xml schemas
are coming of age.  It is no longer appropriate for a W3C activity to say
"well, we won't use them because they aren't here yet". They are here --
there are drafts which you can read and use.

It is now appropriate for any group developing a W3C xml application (such
as P3P, xHTML, etc) to use namespaces and schemas.  These should be seen as
the first, very important, test cases for schema: if xml-schema language
won't do what you want it to do, then get it fixed.

Working across more groups takes time but it leads to a consistent result.
Let's  make sure everything fits together at this stage!

Keep up the good work, everyone.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 21:33:15 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:43 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <3.0.32.19991109133106.00c6f730@pop.intergate.ca>

At 01:21 PM 11/9/99 -0800, David Brownell wrote:
>> ... external parsed entities are evil ...
>
>Bringing morality into it seems ... irrelevant, extremist.

Well, I'm with Eliot.  XML would be altogether better if we'd just
bagged external parsed entities.  All repeat all the corner cases that
I know of are right here.  In particular, since in the history of SGML,
the number of tools that actually did useful things with them was very
small, we have no excuse.  Oh well. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gorden at bnl.gov  Tue Nov  9 21:42:19 1999
From: gorden at bnl.gov (Gorden-Ozgul, Patricia E)
Date: Mon Jun  7 17:16:43 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <698DB793D712D31180B600902746422D8475E1@exchange01.bnl.gov>

Is there a listserv dedicated to more basic SGML/XML issues?  This list
seems to be geared for those planning for or on the 'bleeding edge'.  Any
help appreciated.
TIA

____________________________________
Pat Gorden-Ozgul					
Sr. Systems Specialist			
(631)344-5159					
gorden@bnl.gov				

Brookhaven National Laboratory
Database Development Group
Information Services Division - Bldg. 477
Upton, New York   11967


. -----Original Message-----
. From: Tim Bray [mailto:tbray@textuality.com]
. Sent: Tuesday, November 09, 1999 4:32 PM
. To: David Brownell; xml-dev@ic.ac.uk
. Subject: Re: external parsed entites (was: A unique ID question ?)
. 
. 
. At 01:21 PM 11/9/99 -0800, David Brownell wrote:
. >> ... external parsed entities are evil ...
. >
. >Bringing morality into it seems ... irrelevant, extremist.
. 
. Well, I'm with Eliot.  XML would be altogether better if we'd just
. bagged external parsed entities.  All repeat all the corner cases that
. I know of are right here.  In particular, since in the 
. history of SGML,
. the number of tools that actually did useful things with them was very
. small, we have no excuse.  Oh well. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
. unsubscribe xml-dev
. To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From w.hedley at auckland.ac.nz  Tue Nov  9 21:51:32 1999
From: w.hedley at auckland.ac.nz (Warren Hedley)
Date: Mon Jun  7 17:16:43 2004
Subject: bibiography dtd?
References: <698DB793D712D31180B600902746422D8475C4@exchange01.bnl.gov>
Message-ID: <3828975A.D1D92269@auckland.ac.nz>

"Gorden-Ozgul, Patricia E" wrote:
> 
> I have an industry-provided bibliographic DTD to which I need to apply data
> from Word documents.  Other than a manual solution (clerical cut/paste from
> Word doc to DTD doc) how would one create the DTD ASCII file for the data
> exchange.

Any chance of you posting that DTD (or a link to it) to this list, so that I
can have a look at it?

> This may seem like a dumb question, but I am new to this 'document
> processing' field.

Hardly - this is an extremely nasty problem. If your Word bibliography is
in plain text, then it will prove almost impossible to separate out the
different components of each reference in any automated manner. My first
approach would be to save as text and write a Perl script that separates
each entry by commas - this might speed up the process but would probably
fail for multiple authors and journals.

Not much help at all really.


-- 
Warren Hedley
Department of Engineering Science
Auckland University
New Zealand

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 21:54:18 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:43 2004
Subject: Schemas coming of age: use them
In-Reply-To: <011101bf2af1$79e15a40$e5061812@ridge.w3.org> (timbl@w3.org)
References: <011101bf2af1$79e15a40$e5061812@ridge.w3.org>
Message-ID: <199911092151.PAA04830@bruno.techno.com>


[Tim Berners-Lee:]

> As I have mentioned in various fora including the AC meeting, xml
> schemas are coming of age.  It is no longer appropriate for a W3C
> activity to say "well, we won't use them because they aren't here
> yet". They are here -- there are drafts which you can read and use.

Is this the end of the consensual standardization process at W3C?  Can
the people who are writing these drafts meaningfully withhold their
approval for them, if the Director decides, one day, that the drafts
"have come of age"?

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gorden at bnl.gov  Tue Nov  9 21:54:52 1999
From: gorden at bnl.gov (Gorden-Ozgul, Patricia E)
Date: Mon Jun  7 17:16:43 2004
Subject: bibiography dtd?
Message-ID: <698DB793D712D31180B600902746422D8475E4@exchange01.bnl.gov>

Sure:

<?xml version="1.0"?>
<!DOCTYPE doc SYSTEM "rd.dtd">
<doc>
<rec>
<proj-id>P/ORNL--12345</proj-id> 
<res-org>ORNL</res-org> 
<proj-ttl>The title of the project</proj-ttl> 
<fund-mec>M&O</fund-mec> 
<proj-desc>Description of sample project</proj-desc> 
<poc-name>Johnson, Larry</poc-name> 
<poc-phone>(909)488-1234</poc-phone> 
<sp>EM</sp> 
<br> 
<br-code>EW4010000</br-code> 
<br-cost>$100,000</br-cost>
<br-code>EW5010200</br-code> 
<br-cost>$250,000</br-cost></br> 
<perf-zip>37831</perf-zip> 
<deliverables>SI;HW</deliverables> 
<start-date>19990101</start-date> 
<exp-date>20010531</exp-date> 
<future-cost>FY2000-100000</future-cost> 
<progress>This is the progress report for my project.</progress> 
<future-plans>Here is a sample of using a "less than" sign < inside
text.</future-plans> 
<non-doe-cont>50%</non-doe-cont> 
<pi-name>Smith, Jane</pi-name> 
<pi-affil>ORNL</pi-affil> 
<pi-zip>37831</pi-zip> 
<type-res>B</type-res> 
<asref-no>C/ORNL--54321</asref-no> 
<poc-email>JOHNSON@ORNL.GOV</poc-email> 
<int-where>Canada;Mexico</int-where> 
<subcont-no>A12345</subcont-no> 
<subcont-name>Allied Chemical</subcont-name> 
<publications>This is an example of a publication.</publications> 
<url>http://www.ornl.gov/whatever.pdf</url> 
<pi-phone>(909)444-5555</pi-phone> 
<wpn>EMW0001</wpn> 
<wasn>EM00019</wasn> 
</rec>
</doc>

____________________________________
Pat Gorden-Ozgul					
Sr. Systems Specialist			
(631)344-5159					
gorden@bnl.gov				

Brookhaven National Laboratory
Database Development Group
Information Services Division - Bldg. 477
Upton, New York   11967


. -----Original Message-----
. From: Warren Hedley [mailto:w.hedley@auckland.ac.nz]
. Sent: Tuesday, November 09, 1999 4:51 PM
. To: Gorden-Ozgul, Patricia E
. Cc: 'xml-dev@ic.ac.uk'
. Subject: Re: bibiography dtd?
. 
. 
. "Gorden-Ozgul, Patricia E" wrote:
. > 
. > I have an industry-provided bibliographic DTD to which I 
. need to apply data
. > from Word documents.  Other than a manual solution 
. (clerical cut/paste from
. > Word doc to DTD doc) how would one create the DTD ASCII 
. file for the data
. > exchange.
. 
. Any chance of you posting that DTD (or a link to it) to this 
. list, so that I
. can have a look at it?
. 
. > This may seem like a dumb question, but I am new to this 'document
. > processing' field.
. 
. Hardly - this is an extremely nasty problem. If your Word 
. bibliography is
. in plain text, then it will prove almost impossible to 
. separate out the
. different components of each reference in any automated 
. manner. My first
. approach would be to save as text and write a Perl script 
. that separates
. each entry by commas - this might speed up the process but 
. would probably
. fail for multiple authors and journals.
. 
. Not much help at all really.
. 
. 
. -- 
. Warren Hedley
. Department of Engineering Science
. Auckland University
. New Zealand
. 

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



From w.hedley at auckland.ac.nz  Tue Nov  9 21:58:06 1999
From: w.hedley at auckland.ac.nz (Warren Hedley)
Date: Mon Jun  7 17:16:43 2004
Subject: bibiography dtd?
References: <51ED3F5356D8D011A0B1006097C3073401B16F4D@martinique> <38273806.E06D349F@auckland.ac.nz> <382740A3.788A@hiwaay.net>
Message-ID: <382898E1.B511C84C@auckland.ac.nz>

Len Bullard wrote:
> 
> Good approach.  Question: is it a valid subset?  Will any instance that
> parses by this definition parse with the original?

I'm 99% confident that anything conforming to this DTD would also conform
to the DocBook DTD - I certainly didn't add anything new, just ripped out
the bits that seemed useful. I'm less confident that a DocBook bibliography
would validate against my DTD - there may well be some features missing.

> How should an XML DTD designer signify that this DTD is a
> conformant subset or a variant of a another DTD?

Good commenting ;-)

> Are these one, two, or three namespaces IF a namespace identifier
> resolves to a schema?  This matters if the FPI is ROA for the
> DTD and a label for the namespace identifier.

Too many acronyms for my taste (and limited experience with namespaces),
I'm afraid.



-- 
Warren Hedley
Department of Engineering Science
Auckland University
New Zealand

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Tue Nov  9 22:04:22 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:43 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <698DB793D712D31180B600902746422D8475E1@exchange01.bnl.gov>
Message-ID: <004401bf2afe$444cb200$16beb3c7@PTGRESTON>


----- Original Message -----
From: Gorden-Ozgul, Patricia E <gorden@bnl.gov>
To: 'Tim Bray' <tbray@textuality.com>; David Brownell <david-b@pacbell.net>;
<xml-dev@ic.ac.uk>
Sent: Tuesday, November 09, 1999 4:40 PM
Subject: RE: external parsed entites (was: A unique ID question ?)


> Is there a listserv dedicated to more basic SGML/XML issues?  This list
> seems to be geared for those planning for or on the 'bleeding edge'.  Any
> help appreciated.
> TIA


Try http://listserv.heanet.ie/xml-l.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ht at cogsci.ed.ac.uk  Tue Nov  9 22:05:35 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:16:43 2004
Subject: Schemas coming of age: use them
In-Reply-To: "Steven R. Newcomb"'s message of "Tue, 9 Nov 1999 15:51:09 -0600"
References: <011101bf2af1$79e15a40$e5061812@ridge.w3.org> <199911092151.PAA04830@bruno.techno.com>
Message-ID: <f5bu2mvtj6e.fsf@cogsci.ed.ac.uk>

I'd like to write a lengthy reply about the surprising willingness to
see conspiracy where encouragement was all that was intended, but I'm
too busy trying to pull together the hard work underway in the XML
Schema WG for the next draft to bother . . . :-)

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From w.hedley at auckland.ac.nz  Tue Nov  9 22:09:46 1999
From: w.hedley at auckland.ac.nz (Warren Hedley)
Date: Mon Jun  7 17:16:43 2004
Subject: bibiography dtd?
References: <698DB793D712D31180B600902746422D8475E4@exchange01.bnl.gov>
Message-ID: <38289B83.239E1698@auckland.ac.nz>

Hi Gordon

The style of XML document you've included does not really constitute
what I would consider to be an average bibliographic reference, it
contains a lot of extra project-based information. Would you be able
to tell me where you grabbed the DTD from, so that I can get a bit
more of an idea of what it's supposed to be used for, and if there
is a part of it that is relevant to scientific referencing?

Thanks


-- 
Warren Hedley
Department of Engineering Science
Auckland University
New Zealand

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov  9 22:34:26 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:16:43 2004
Subject: Schemas coming of age: use them
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F2780D7@MDYNYCMSX1>

>> As I have mentioned in various fora including the AC meeting, xml
>> schemas are coming of age.  It is no longer appropriate for a W3C
>> activity to say "well, we won't use them because they aren't here
>> yet". They are here -- there are drafts which you can read and use.

>Is this the end of the consensual standardization process at W3C?  Can
>the people who are writing these drafts meaningfully withhold their
>approval for them, if the Director decides, one day, that the drafts
>"have come of age"?

Hey Steve, he does go on a bit more after that first paragraph. In
particular, in the second: 

  "These should be seen as the first, very important, test cases for schema:
"
  "if xml-schema language won't do what you want it to do, then get it
fixed."

I think the idea is that, if anyone's going to develop some use-cases upon
which to form judgements of the W3C's Schema language, it's not going to be
CommerceOne, ODI, or any other companies with vested interests in the other
schema proposals. (One or two Redmond companies also come to mind.) If
xml-dev people don't pound on the proposed version to figure out what we
like and what we don't, we shouldn't complain too much when it's done. 

Merely writing schemas only tests their usefulness at modeling the data in
our heads. Writing apps that use these schemas is what would be really
useful, and so far IBM's xml4j EA is the only thing out there that I know of
that allows this. I believe the most recent release supports the parts of
the September XSDL draft that are backward-compatible with XML 1.0 and some
of the data typing, although my brief tries haven't gotten the checking of
data types to work yet. I look forward to getting it to work; anyone else
geeky enough to consider such endeavors to be fun should join in. Just paste
Appendix B from Parts 1 and 2 of the WD into their own files, point at them
from a document in a validating XML editor, and go at it.

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii


-----Original Message-----
From: Steven R. Newcomb [mailto:srn@techno.com]
Sent: Tuesday, November 09, 1999 4:51 PM
To: timbl@w3.org
Cc: chairs@w3.org; xml-dev@ic.ac.uk; w3c-xml-plenary@w3.org
Subject: Re: Schemas coming of age: use them



[Tim Berners-Lee:]

> As I have mentioned in various fora including the AC meeting, xml
> schemas are coming of age.  It is no longer appropriate for a W3C
> activity to say "well, we won't use them because they aren't here
> yet". They are here -- there are drafts which you can read and use.

Is this the end of the consensual standardization process at W3C?  Can
the people who are writing these drafts meaningfully withhold their
approval for them, if the Director decides, one day, that the drafts
"have come of age"?

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:43:45 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:43 2004
Subject: Why do we write standards?
References: <Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600">
	 <003901bf271e$fe5a5be0$099918d1@docuverse1>
	 <3822FC81.D077B6F7@prescod.net>
	 <m3iu3givwn.fsf@localhost.localdomain>
	 <3825E52F.31E71581@prescod.net> <199911091339.IAA01153@hesketh.net> <199911091754.LAA04564@bruno.techno.com>
Message-ID: <3828B8FF.868@hiwaay.net>

Steven R. Newcomb wrote:
> 
> * Because ISO standards are at their best when they are even-handedly
>   responsive to civilization-wide requirements, rather than merely the
>   shorter-sighted desires of some particular industry or consortium.
>   When working on ISO standards, I may not feel like I'm going to get
>   rich, but I know that I'm working to make all of our descendants a
>   lot richer.  Will ISO standards pay off in that way?  I don't know.
>   I hope so.

1.  The consortium is the inner loop of set of processes that must 
be responsive to a hundred markets.

2.  ISO is the outer loop that must be responsible to the needs of a 
single market.

When the inner and outer loops bind values in shared namespace, the 
system stays stable even while dynamic.  

We write standards because there is a process for doing so.  We use
standards as a means 
to communicate and coordinate across time through use of precisely
defined 
and shared understanding of a set of symbols/names.  You are a
musician.  You already 
know why orchestras need scores, how they evolved, and how messy 
the namespace they use is (languages overlaid over time) and how 
difficult it is to fix that (too many of us understand andante 
who would be *offended* if we read *walking speed*).

We make no progress as long as we remain hungry ghosts who 
live by draining the strengths of others.  We make standards 
so we may rise about that low realm.  Those who wish to 
remain pretas have found their own desires in accordance 
with their habits.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:43:59 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:44 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109133106.00c6f730@pop.intergate.ca>
Message-ID: <3828BCB0.E87@hiwaay.net>

Tim Bray wrote:
> 
> Well, I'm with Eliot.  XML would be altogether better if we'd just
> bagged external parsed entities.  All repeat all the corner cases that
> I know of are right here.  In particular, since in the history of SGML,
> the number of tools that actually did useful things with them was very
> small, we have no excuse.  Oh well. -Tim

Umm, just as IADS did with DTDs, enlightened users won't use them 
where they aren't useful.  We can't bag the cat once it is in the alley 
unless we are faster than the cat, or know where it sleeps.  In either 
case, we will have a mad cat when we take it out of the bag.

len  (the guy who wanted to bag parameter entities too)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:43:47 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:44 2004
Subject: Schemas coming of age: use them
References: <011101bf2af1$79e15a40$e5061812@ridge.w3.org>
Message-ID: <3828B9D0.5293@hiwaay.net>

Tim Berners-Lee wrote:
> 
> It is now appropriate for any group developing a W3C xml application (such
> as P3P, xHTML, etc) to use namespaces and schemas.  These should be seen as
> the first, very important, test cases for schema: if xml-schema language
> won't do what you want it to do, then get it fixed.

Excellent.

> Working across more groups takes time but it leads to a consistent result.
> Let's  make sure everything fits together at this stage!

How can a namespace enable us to discover a record of authority by 
which we may determine which variant or subset of the definition 
is in effect for some time slice of a process?

It is important because we will not have a single definition for 
some processes which may think to name within a single standard.  
For example, the timing models or concepts of SMIL and VRML may 
not be compatible although they do overlap considerably.  We 
require a means to diffentiate the non-compatible models.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:43:50 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:44 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <199911052037.VAA02691@chimay.loria.fr>
		 <3824E917.78555C71@isogen.com> <199911071821.MAA03281@bruno.techno.com> <3826E29D.6BAFF240@isogen.com> <3828904C.50A80CEF@pacbell.net>
Message-ID: <3828BB43.3A91@hiwaay.net>

David Brownell wrote:
> 
> > Eliot The K asserts ... external parsed entities are evil ...

> 
> Or in short, the tool can be misused, so ban the tool.  I'm
> not convinced, nor am I likely to be.  Applied with consistency,
> that makes banging rocks together to make fire become evil.

Not really.  You agree to a set of tests by which you determine 
if:

o  The rocks are the right rocks to make fire

o  The combustible is in combustible condition (not wet)

o  An igniting accelerant is required or available

o  A set of tests are available

o  What to do if any or all of the above conditions aren't met

Known as conformance tests for systems, they are written 
for the contract and referenced from there.  In all cases 
I can think of, they have a timing/duration value set whose 
opening and closing events are also authoritatively stated.

External parsed entities aren't evil.  They just smell 
funny after you have to bake the namespace.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:43:45 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:44 2004
Subject: Why do we write standards?
References: <Paul Prescod's message of "Sun, 07 Nov 1999 14:46:39 -0600">
	 <003901bf271e$fe5a5be0$099918d1@docuverse1>
	 <3822FC81.D077B6F7@prescod.net>
	 <m3iu3givwn.fsf@localhost.localdomain>
	 <3825E52F.31E71581@prescod.net> <199911091339.IAA01153@hesketh.net>
Message-ID: <3828B4AF.3A50@hiwaay.net>

Simon St.Laurent wrote:
> 
> We've got the core set.  Why not let users experiment with that basic set
> of tools before we try to slap them in straitjackets?  I hear people on
> this list insisting on the need for constraints, for fixed structures, for
> all that stuff that made sense when computers were (relatively) slow and
> stupid and data structures were hard to convert from one form to another.

Make schemas time-dynamic systems and enable the namespace to 
reflect that volatility and variant.  Shouldn't be that hard if 
you agree that registries are just records of authority and that 
a given ROA can be said to dominate discourse within the process 
space.

The reason I originally suggested using a time model from 
a music standard for enterprise management is that it contains 
an asynchronous model of gestures for synchronizing a performance.  
The most obvious problem of XML-centric, namespace authorities is 
the same as any other set of related standards:  discovering 
redundancy and differentiating it from overlapping dimensional 
members.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:44:01 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:44 2004
Subject: Schemas coming of age: use them
References: <011101bf2af1$79e15a40$e5061812@ridge.w3.org> <199911092151.PAA04830@bruno.techno.com> <f5bu2mvtj6e.fsf@cogsci.ed.ac.uk>
Message-ID: <3828BE7F.1751@hiwaay.net>

Henry S. Thompson wrote:
> 
> I'd like to write a lengthy reply about the surprising willingness to
> see conspiracy where encouragement was all that was intended, but I'm
> too busy trying to pull together the hard work underway in the XML
> Schema WG for the next draft to bother . . . :-)

Unkind, Henry.  Steve is recognizing that Tim's *encouragement* from 
the position of Director to w3c chairs has "moral majesty", therefore, 
is a real order to get in line with the draft(s).  

That said, we have a lot of work to do to use the schemas particularly 
where we have language bindings via IDLs to do.  Because we have many 
separate efforts and different authorities to which we must determine 
how the names bind, we also will be cleaning this up for a long time.  
When we have to bind to the ISO level, we also have to work within 
five year change cycles.  So, it would have been a good idea for 
Tim to ask if everyone felt ready to make the change.  Personally, 
I'm for it because I need dynamic schemas to cope with time-volatile 
definitions.

Otherwise, we're off to the races.  Place your bets, gentlefolk.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 00:43:57 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:44 2004
Subject: Apache To Take On XML Efforts
References: <805C62F55FFAD1118D0800805FBB428D02BC008F@cc20exch2.mobility.com> <v04220806b44e0a875add@[171.66.196.146]>
Message-ID: <3828B6B5.64CD@hiwaay.net>

Avi Rappoport wrote:
> 
> This came in the InternetWorld Newsletter this morning, the site is
> supposed to be <http://www.internetworldnews.com> but it's down, so
> I'll extract useful bits.  The other useful URL seems to be
> <http://xml.apache.org>
> 
> ----------------
> Apache To Take On XML Efforts
> By Nate Zelnick

Brian Behlendorf has made very valuable contributions 
on the Internet in three different communities.  Hats off to 
the Apache members.  Good folks.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 00:57:32 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:44 2004
Subject: Schemas coming of age: use them
Message-ID: <3.0.32.19991109165810.01502ea0@pop.intergate.ca>

At 06:18 PM 11/9/99 -0600, Len Bullard wrote:
>How can a namespace enable us to discover a record of authority by 
>which we may determine which variant or subset of the definition 
>is in effect for some time slice of a process?

It can't.  Yes, we need a way to do this, but namespaces weren't designed
for this and they won't do the job.

>It is important because we will not have a single definition for 
>some processes which may think to name within a single standard.  
>For example, the timing models or concepts of SMIL and VRML may 
>not be compatible although they do overlap considerably.  We 
>require a means to diffentiate the non-compatible models.

Yup. -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 00:57:40 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:44 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <3.0.32.19991109165751.014f6360@pop.intergate.ca>

At 06:30 PM 11/9/99 -0600, Len Bullard wrote:
>We can't bag the cat once it is in the alley 
>unless we are faster than the cat, or know where it sleeps.  In either 
>case, we will have a mad cat when we take it out of the bag.

I enjoyed reading that but I have *no* idea what you mean, Len... -T.

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



From mda at discerning.com  Wed Nov 10 01:42:15 1999
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:16:44 2004
Subject: Schemas coming of age: use them
In-Reply-To: <3828B9D0.5293@hiwaay.net>
Message-ID: <1571432856.942169270@MDAXKE>

(I love how we all immediately have alternative exegetical
analyses of every one of timbl's utterances...)

This read to me as a exhortation *within* w3c to eat their
own dogfood -- note the cc to w3 aliases and the narrowing
to "any group developing a *W3C* xml application" (emphasis mine).
Unless that was meant to reinforce some sort of w3c branding or
trademark on "xml"....

Seems perfectly reasonable to me to try to get the different
standards groups within a single standards body to try to
use each others' stuff. The apparent efforts to unify the
use of XPath in XSLT, XQL, and elsewhere, is to me a great
example of this.

As for whether those of us on the outside will bother with
these standards, that obviously depends on our judgment of their
usefulness and design (insert rant about P3P here), or
their stability (look how long XLink is taking, and that is
a simpler area than schemas).

There is also the issue that the areas that would be
most critical for standards re-use (xlink, info set, modules)
seem to be the slowest moving. I don't know if that slowness
is because of the multiple demands, or because it is thought
to be more exciting to do whole applications/protocols like P3P,
so that is where all the energy is going.

Of course the real test of a standard -- some would say a pre-requesite
for its ratification -- is its use in real applications and
implementations, not in its use in other standards.

-mda

> Tim Berners-Lee wrote:
>> 
>> It is now appropriate for any group developing a W3C xml application (such
>> as P3P, xHTML, etc) to use namespaces and schemas.  These should be seen as
>> the first, very important, test cases for schema: if xml-schema language
>> won't do what you want it to do, then get it fixed.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 01:54:02 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:44 2004
Subject: Why do we write standards?
In-Reply-To: <805C62F55FFAD1118D0800805FBB428D02BC008F@cc20exch2.mobility.com>
Message-ID: <000d01bf2b1e$b872ae80$099918d1@docuverse1>

David Hunter wrote:
>The *new* part is somehow managing to combine XHTML documents 
>with other XML documents.  This is the part that could be
>considered standardization in advance of implementation.  So
>if people say <overstatement?>"let's just say the XHTML
>namespace is 'blah', do what you want with the grammar and
>we'll standardize it later [maybe]"</overstatement?>, that
>seems completely backwards to me.  And actually starts us

*sigh*  Here we go again:

But we are not talking about wild wild west where anything goes.
We already have the following specs in various states which places,
imho, sufficient level of constraints in the past and in the future
to guide the lost and to punish the rebels.

HTML 4.0 specification
	http://www.w3.org/TR/REC-html40/
XHTML 1.0
	http://www.w3.org/TR/xhtml1/
XHTML 1.1 - Module-based XHTML
	http://www.w3.org/TR/xhtml11
Modularization of XHTML
	http://www.w3.org/TR/xhtml-modularization
Building XHTML Modules
	http://www.w3.org/TR/xhtml-building
	
<rant>
The primary nemesis of standardization is time.  Time is also the
key ingredient of warfare; anyone engaged in any competitive
process must pay close attention to time.  So it is not surprising
that some of us wants to take seemingly obvious and safe shortcuts.

I am as frustrated as a dirt covered sergent in the middle of a
battlefield who has just been told that he will have to wait for
the bullets because the manufacturers have standards to consider
for field inter-operability.  Nuts!  Get me some standard stones!
</rant>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 02:07:39 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:45 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <3828BCB0.E87@hiwaay.net>
Message-ID: <001201bf2b20$a13adb00$099918d1@docuverse1>

>Umm, just as IADS did with DTDs, enlightened users won't use them 
>where they aren't useful.  We can't bag the cat once it is in 
>the alley unless we are faster than the cat, or know where it sleeps.
>In either case, we will have a mad cat when we take it out of the bag.

If you bag a rat into the bag with the cat, I don't think
you will have a mad cat in the bag.

To celebrate the new release of the Canonical XML spec, here
is the canonical form of the bag:

<bag><cat><rat/></cat></bag>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 02:10:30 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:45 2004
Subject: bibiography dtd?
References: <698DB793D712D31180B600902746422D8475C4@exchange01.bnl.gov>
Message-ID: <3828D324.2D41@hiwaay.net>

Gorden-Ozgul, Patricia E wrote:
> 
> This may seem like a dumb question, but I am new to this 'document
> processing' field.

Len writes to Warren?

> . How should an XML DTD designer signify that this DTD is a
> . conformant subset or a variant of a another DTD?  Are
> . these one, two, or three namespaces IF a namespace identifier
> . resolves to a schema?  This matters if the FPI is ROA for the
> . DTD and a label for the namespace identifier.

Is the FormalPublicIdentifier the legal name of the namespace? 
Outermost parentheses in the oldTongue?  ROA:  record of 
authority. dominant namespace for aggregate.  If in contract, 
I must cite the record of authority for the defined item, 
I require it to be a singleton.  No Bifurcation at Root.

Sorry, mad'm, if the thread avoided your question.  
The crazies say, "Welcome!"

XML: Eight Noble Concepts (it's all about names)

1.  Markup:    Trees of names.
2.  Hyperness: Locations are points in space or time.
3.  Identity:  Locations bound to names enable persistence and
uniqueness.
4.  Systems:   Identities bound into a namespace.
5.  Schemas:   Systems to bind identities
6.  Mapping:   schemas whose trees are related by n-dimensional bindings
7.  N-dimensional binding:  a named vector of the schemas that produces
an intersection space 
8.  Facts:     the named values within the intersections

I won't go into that. :-)

Your problem:

> I have an industry-provided bibliographic DTD to which I need to apply data
> from Word documents.  Other than a manual solution (clerical cut/paste from
> Word doc to DTD doc) how would one create the DTD ASCII file for the data
> exchange.

You want to map the names 

o  in a source namespace (RTF) 

o  to a target namespace (DTD).

The source is the collection of instances, or documentation of instances 
to be transformed to the target namespace.  Create a table where 
the names in the source definition are mapped to the target.

DTD = Target namespace.  You are transforming it to this target.  The
DTD 
describes a tree of names.   Its just a tree of named things.  
Look at the TreeView object you use every day in many 
applications, and that is a good geometric model for what 
XML elements/attributes (trees of names) model. 

DOC = source collection (word does not have a DTD.  You 
must use an export format and figure out which one you 
want to work with.  some choices here are the HTML saveAs or the RTF 
(RichTextFile - doc's native format for all practical purposes).

o  If you do not have it, download the RTF spec

The export format with the most information is also the one that is
hardest 
to use:  RTF.   The RTF namespace is complex, but it is documented and 
reasonably regular.  The problem is working out what in that namespace
matches the 
names in the DTD.  

Eg, how do you get <par to become <p>?   If you 
don't have an RTF book, use the rtf saveAs, open that file in ASCII, 
then use the replace command of an editor like Professional File Editor, 
PFE, to substiture \n and the <par with \n<par.   It matches strings 
inside braces, so, use a substition of \n and the brace to separate 
sections.  

Do that with all of the names provided in the RTF namespace.  Looking
them 
up in the RTF spec, you will find these are the attributes that are
setting things like 
bold, font name, and so on.  You use that information to figure out what 
the format identifies in the namespace of the TARGET DTD.  Sorry, but 
because of the way this works, and because the SaveAs RTF feature 
produces such badly formattted data for reuse, you get to work awhile 
at this because you are actually tagging someone elses style and 
using their choices to infer names in the target.  The bad news, 
this is an inconsistent source of sources;  the good news, for practical 
purposes, people are reasonably consistent about how they do this.

So.. slug work for the conversionHead.

Or find some shareware or freeware that preformats RTF for conversion. 
My guess is, XSLT can be used to build this now. :-)

The easy manual way is to use the SaveAsHTML and map the HTML to the 
target DTD directly.  Why?  Depending on the consistency and 
application of the style, the productions are regular enough 
in the HTML source  to capture most of the important information 
for a downtranslation with restore.  By restore, the application 
of the target system restores the lost information.  Up translation 
is usually a little lossy, but not excessively so in this case.  
The truth is, if the source is doc, most of the important information 
is in the headers.  Get the text nodes out of the formatting 
goop, and you will have most of what you need.  What you get 
will look a lot like... SaveAsHTML.  Bare, but a simple enough 
subset of HTML that mapping back up is easy because the productions 
are regular.

The analysis of the RTF won't yield enough information to make that 
mapping a lot more useful if page fidelity is not an issue.  If page 
fidelity is still an issue, you have to analyze the RTF to get a 
closeEnoughForLegalWord fidelity.  Otherwise, just map the easily 
recognized structures (what SaveASHTML actually produces) and 
clean up a bit afterwards.  Map the HTML structures/names, which you 
know, to the matching structures/names (if any) of the target DTD. 
If they don't match lexically, (p Is p), you work out the match 
semantically (P isA p).  For a biblio DTD, that should be really 
straightforward.  You may have to track down some authors to get 
the information Word puts in those nice sets of global doc 
attributes that no one uses.

I hope this helps.  If not, ask more questions.  This list still 
answers questions best it can.

peace,

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 02:48:55 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:45 2004
Subject: Schemas coming of age: use them
In-Reply-To: <1571432856.942169270@MDAXKE>
References: <1571432856.942169270@MDAXKE>
Message-ID: <199911100247.UAA00592@bruno.techno.com>

[Mark D. Anderson:]
> This read to me as a exhortation *within* w3c to eat their
> own dogfood -- note the cc to w3 aliases and the narrowing
> to "any group developing a *W3C* xml application" (emphasis mine).

Oops.  If that's what Tim is up to, then I apologize for my
uncharitable thoughts, and I now say instead, "Good move, Tim!"

(I hadn't seen the ambiguity of "W3C XML application".  I assumed
"W3C" modified "XML" rather than "application".  Thanks, Mark.)  

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 02:58:36 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:45 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
Message-ID: <3828D62A.5138@hiwaay.net>

Tim Bray wrote:
> 
> At 06:30 PM 11/9/99 -0600, Len Bullard wrote:
> >We can't bag the cat once it is in the alley
> >unless we are faster than the cat, or know where it sleeps.  In either
> >case, we will have a mad cat when we take it out of the bag.
> 
> I enjoyed reading that but I have *no* idea what you mean, Len... -T

External parsed entities are a done deal for XML 1.0.  
But hey, just a version number, right?  We get to 
have this fight again. :-)

If you and eliot truly think they are bogus and a 
screwup to use, sounds like an issue to me.  

How do subdocs fix this problem, Eliot?  Or 
better, what problems do subdocs fix for markup systems?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 02:58:40 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:45 2004
Subject: Schemas coming of age: use them
References: <3.0.32.19991109165810.01502ea0@pop.intergate.ca>
Message-ID: <3828DE7F.FF1@hiwaay.net>

Tim Bray wrote:
> 
> At 06:18 PM 11/9/99 -0600, Len Bullard wrote:
> >How can a namespace enable us to discover a record of authority by
> >which we may determine which variant or subset of the definition
> >is in effect for some time slice of a process?

> It can't.  Yes, we need a way to do this, but namespaces weren't designed
> for this and they won't do the job.

We need a means to name aggregate namespaces. 
That is the level of definition required to 
name complex document types for business.  
Whatever a namespace is lexically, in practice, 
it appears to be the name or near name of the contract 
depending on how you feel about FPIs.
 
As spec'd, no.  As applied?   The 
namespaces I see are system application 
identifiers mapping to vendor framework objects.   
If I buy an object from a business, they control the 
record of authority for the item I purchase.  
Yes, not all namespace names are ROA, but some
are.  In these cases, it seems the business 
transaction is one where that is better to 
know apriori.  That is why FPIs were important. 
It is the Published name.  The objection in 
TimBLs Myth's paper on names and location is the 
ultimate need for an authoritative registry.  

Outermost parentheses are systemic.

So... we leave it to BizTalk and OASIS to 
fight over until someone is left standing? 
Ok.  Keiretsu it is: businesses defined 
by their registered namespaces in publically 
controlled, owned and operated registries.

How do they aggregate?

The URI/URN may not have to directly map to 
the FPI, but if not, should map to something 
that lets me find one.  LexicalClarifier or 
not, it looks like a URL.  Click.  If not 
by spec, then by common practice.  Maybe 
the easiest thing is to use the FPI on the 
right side of the colon.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From AlanM at SYNECTICS.Soft.net  Wed Nov 10 04:56:07 1999
From: AlanM at SYNECTICS.Soft.net (Alan Menezes)
Date: Mon Jun  7 17:16:45 2004
Subject: MSXML help
Message-ID: <1F4436D26763D2119B8800A0C9DE68979AA7BA@MAIL>


Hi all,
Can soembody tell me where i can get documentation for MSXML COM component.
I want details on the Interfaces and Methods.
thanks,
Alan


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 10:02:57 1999
From: grove at infotek.no (Geir Ove Grønmo)
Date: Mon Jun  7 17:16:45 2004
Subject: GPS - Groves and Property Sets for Python 0.10
Message-ID: <GROVE-829046oe8o.fsf@pc-grove.infotek.no>

Hi,

I'm pleased to announce the first release of GPS - Groves and Property
Sets for Python.

Suggestions and bug reports should be sent to: grove@infotek.no

Geir O. Gr?nmo

--------------------------------------------------------------------------

Title: GPS - Groves and Property Sets for Python

Version: 0.10
Released: November 10th 1999

Author: Geir O. Gr?nmo, grove@infotek.no
License: GPL

Homepage: http://www.infotek.no/~grove/software/gps/index.html

- --
>>> What is GPS?

GPS is an implementation of the groves and property set concepts
defined in the HyTime and DSSSL standards. GPS is written in Python,
and should work* on any platform to which Python have been ported -
including the Java Platform.

There are two implementations in the current distribution, one
in-memory implemention and one that supports ZODB - the Zope Object
Database. Both groves, property sets and grove plans can be made
persistent by the ZODB implementation.

- --
>>> Features

 o Loading of property sets from documents conforming to the Property
   Set DTD, or any derived DTD [requires architectural processing].

 o Grove plans. Default grove plans is automatically created by
   wrapping a GrovePlan object around a property set. Inclusion and
   omitting of modules, classes and properties are fully supported.

 o Two grove node implementations, both generic classes for
   representing grove nodes.

 o ZODB - Zope Object Database versions of all grove, property set and
   grove plan classes.

 o Module for building XML groves from SAX event streams. This module
   also contains a class for emitting SAX events by walking XML groves.

 o Sample Property Sets

- --
>>> Requirements
   
  - Python 1.5.2 or newer [3]
  - An SGML/XML parser with a SAX driver
  - SAX for Python [4]
  - xmlarch 0.25, optional unless architectural processing is needed [5]

- --
>>> References

[1] http://www.jpython.org/
[2] http://www.ornl.gov/sgml/SC34/
[3] http://www.python.org/
[4] http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxlib.html
[5] http://www.infotek.no/~grove/software/xmlarch/index.html
[6] http://www.infotek.no/~grove/software/gps/licence.html

* The ZODB implementation won't work in a Java environment, since the
ZODB contains code written in C.

--------------------------------------------------------------------------

<P><A HREF="http://www.infotek.no/~grove/software/gps/index.html">GPS
- Groves and Property Sets for Python version 0.10</A> an
implementation of the groves and property set concepts defined in the
HyTime and DSSSL standards. (10-Nov-1999)

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



From marko.zerdin at ixtlan-team.si  Wed Nov 10 10:53:59 1999
From: marko.zerdin at ixtlan-team.si (Marko Zerdin)
Date: Mon Jun  7 17:16:45 2004
Subject: MSXML help
Message-ID: <C96331EC2CDDD21191DC080009F1823B159A38@NETSTAR>

There is help for MSXML on MSDN (best if you have it on CD), but there are
no items related to this topic in index, so you just have to do a full
search (e.g. try IXMLDOMNode, and from there you'll be able to come to all
the rest through links).

-----Original Message-----
From: Alan Menezes [mailto:AlanM@SYNECTICS.Soft.net]
Sent: Wednesday, November 10, 1999 5:54 AM
To: xml-dev@ic.ac.uk
Subject: MSXML help



Hi all,
Can soembody tell me where i can get documentation for MSXML COM component.
I want details on the Interfaces and Methods.
thanks,
Alan


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



From anderst at toolsmiths.se  Wed Nov 10 11:18:57 1999
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:16:45 2004
Subject: XML Schema and international Booleans
Message-ID: <3828CDB9.24D5EC1C@toolsmiths.se>

Hi All

While reading XML Schema part 2: Datatypes, looking the boolean data
type
I found this statement:
"An instance of a datatype that is defined as boolean can have the
following legal lexical values {true, false}. The
lexical representation is fixed and cannot be changed. The lexical
representation facet is not supported."

Does this mean that I cannot create sub types of boolean which allows
other languages  than English?
This is neccesary because in Swedish "true"="sant" and "false"="falskt"

What I want to use is something like...

<datatype name="myBoolean">
     <basetype name="boolean"/>
     <enumeration>
        <literal> 0  </literal>
        <literal> 1  </literal>
        <literal> sant  </literal>
        <literal> falskt  </literal>
        <literal> true  </literal>
        <literal> false  </literal>
     </enumeration>
</datatype>

However here the binding between literal and boolean value is missing.

Im I missing something here ?

/Anders
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/  Financial Toolsmiths AB  /
/  Anders W. Tell           /
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Wed Nov 10 13:33:13 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:45 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <009301bf2b7f$d8c037a0$a3bdb3c7@PTGRESTON>

----- Original Message -----
From: Gorden-Ozgul, Patricia E <gorden@bnl.gov>
To: 'Tim Bray' <tbray@textuality.com>; David Brownell <david-b@pacbell.net>;
<xml-dev@ic.ac.uk>
Sent: Tuesday, November 09, 1999 4:40 PM
Subject: RE: external parsed entites (was: A unique ID question ?)


> Is there a listserv dedicated to more basic SGML/XML issues?  This list
> seems to be geared for those planning for or on the 'bleeding edge'.  Any
> help appreciated.
> TIA


Try http://listserv.heanet.ie/xml-l.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 15:31:13 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:16:45 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
 <3828D62A.5138@hiwaay.net>
Message-ID: <38298DE0.737E814C@isogen.com>

Len Bullard wrote:
> 
> Tim Bray wrote:
> >
> > At 06:30 PM 11/9/99 -0600, Len Bullard wrote:
> > >We can't bag the cat once it is in the alley
> > >unless we are faster than the cat, or know where it sleeps.  In either
> > >case, we will have a mad cat when we take it out of the bag.
> >
> > I enjoyed reading that but I have *no* idea what you mean, Len... -T
> 
> External parsed entities are a done deal for XML 1.0.
> But hey, just a version number, right?  We get to
> have this fight again. :-)
> 
> If you and eliot truly think they are bogus and a
> screwup to use, sounds like an issue to me.
> 
> How do subdocs fix this problem, Eliot?  Or
> better, what problems do subdocs fix for markup systems?

By "subdocs" I presume you mean the use of separate documents to define
a single logical "compound" document (the SGML concept of "subdoc" is in
fact a red herring--what's important is the use of separate documents,
not the fact that they are declared as SUBDOC entities--thus the lack of
SUBDOC in XML is absolutely no loss). It solves the problem by forcing
you to use and manage truly reusable objects, rather than justing doing
syntactic copy and paste through the inclusion of external parsed
entities. 

It also forces you to recognize that all use-by-reference needs to occur
at the semantic (DOM, grove) level, not the syntactic level. Once you
realize that, all sorts of apparently hard problems or non-sensical
cases become easy and quite sensical, because we are out of the
syntactic domain and into the semantic domain. For example, it is
non-sensical for one element to be replaced by another element in
another document at the syntactic level (parse time), but it is
perfectly sensical for an element node to redirect to another element
node in another DOM and the processing needed to achieve this is
trivial:

# See if node is a redirection and resolve it:
try node.atts["redir"]:
   pointer = node.atts["redir"].value
   node = xpath.resolve_pointer_to_node(pointer)
except IndexError:
   # No redir attribute, just go on as before

It couldn't be easier at this level. All that's required is that your
processing software understand the semantics of the documents that might
be pulled together this way, which might of course use different
document types, but that's no different from needing to understand a
document that uses elements with different namespace prefixes, so it's a
constant part of the XML processing problem and this approach doesn't
change it (except to possibly make it both more obvious that the problem
exists and clearer as to how you define a framework for handling the
case).

The problem with external parsed entities is that they are not true
objects in the sense that they have no independent existence outside the
contexts in which they are used--they cannot be parsed or validated in
isolation and must conform *syntactically* to all the contexts they are
used. Thus the problems with ID conflict, entity names, etc. When using
multiple documents, each element maintains its original document context
and therefore its fundamental identity, so there is no possibility of ID
or name conflict and you can always examine the element in its original
context as well as in any contexts in which it might be used.

Of course, if you want to write a transform that generates a new single
instance as output, you have to disambiguat the names and IDs, but
there's no programming difficulty there, it's just an exercise in
rewriting of pointers and, possibly, applying name-space prefixes to
element type names (if you're so inclined). But this is only one way to
take advantage of semantic use-by-reference--you should never assume
that the processing result of compound document processing is another
XML document. Using GroveMinder we have a grove-aware browser that does
all this resolution dynamically at run-time, generating HTML as output.
There's nothing particularly difficult or inventive about this except
that we did it (and that it happens to implement the part of the HyTime
standard that deals with use-by-reference, the value reference
facility).

Note also that if, for example, XLink made a clear distinction between
use-by-reference relationships and hyperlink relationships, that it
would be clearer how one can have a highly-generic, standards-based
infrastructure for doing this stuff.  As it is, you can define your own
conventions for using XLinks to mean use by reference (the "show=embed"
part of XLink is almost there, but it is not sufficiently flexible. For
example, it doesn't let you define the value of an attribute by
reference, which is quite useful, if not a hard requirement for certain
problems).

By using independent documents you get objects (documents) that have
their own independent existence. They can be reliably re-used because
they are combined with other documents *semantically*, not
syntactically, at the processing level. That is, I construct a bunch of
DOM trees (or groves) and then another layer of processing decides how
to use them together. No document directly interfers with any other. Of
course, there will be dependencies between the documents, such as one
document linking to something in another document.

Because the processing of compound documents is a separate layer, there
can be many different ways of processing the same compound document and
therefore different sets of constraints that you might want to enforce.
You can have a policy that says all the members of the document must
have the same DTD or maybe you don't care because your processing isn't
DTD sensitive (e.g., a generic XML structure browser). The system can be
more or less sophisticated depending on your requirements. You don't
have to do twisted things like use name spaces to disambiguate element
type names in the source documents or rationalize all the documents to a
single over-arching document type. Individual documents can be optimized
for their own local purposes and still combined together meaningfully
with other documents, given some rules for playing nice together (e.g.,
Architectures, architypes, etc.).

Once you've built the infrastructure to handle this way of doing things,
the range of problems you can solve and the range of requirements you
support increases dramatically and the incremental cost of the system
drops rapidly.

I note that tools like Framemaker and Wordperfect (and I think even
Word) have *always* worked this way. In Framemaker, for example, a
"book" is composed of multiple documents. Each document is completely
syntactically independent of the other documents in the book: it can
have its own templates, customizations, etc. The addressing between
documents for cross references and hyperlinks is document-to-document
addressing because each document establishes its own ID name space in
Framemaker. There is no syntactic interference between different
documents in the same book.  [NOTE: this is not true for the SGML
version of Framemaker--for whatever reason, the designers chose not to
carry this model into the SGML version, which they could have done very
easily.]

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.S.Brothers at EMCIns.Com  Wed Nov 10 16:22:46 1999
From: Michael.S.Brothers at EMCIns.Com (Michael S. Brothers)
Date: Mon Jun  7 17:16:45 2004
Subject: Why do we write standards?
In-Reply-To: <38275646.4727BC3D@pacbell.net>
Message-ID: <SIMEON.9911101038.B@PC7155.emcins.com>

This thread is fascinating. I liken much of what I have heard to the 
efforts to standardize HDTV, and if you look at that, it's hard to call 
standardization anything else but good for consumers. Broadcasters beam 
one type of signal, sets receive one type of signal. The plus side is 
that once the standard was established, all industry participants had 
access, and any company could start producing broadcast hardware or 
HDTV sets. Thus, consumers will reap the benefits of competition 
between Sony, Philips/Magnavox, Toshiba, etc by having a choice of 
features and lowering prices as the technology matures. Without the 
standard, we would have had Beta vs. VCR all over again.

Things like TCP/IP and HTTP, which became standards, propelled the Web. 
Absence of standards led to the current situation in operating systems, 
where one, through sheer genius of marketing and not ease of use or 
having "freedom to innovate", became the de facto stadard. So now we 
can have lawsuits, people who use Linux or Mac OS looking down their 
noses at Windows users, browser incompatibility leading designers to 
take more into account to put up a storefront on the Web than they 
should, etc. In short, a bad situation.

Standards are not Socialist, nor are they in the best interest of a 
consortia, rather are the key to true consumer freedom. Perhaps the W3C 
is not the body to do it, but perhaps it is as well. I don't know. But 
I applaud any attempts to take all ideas for solving a problem, 
bringing the ideas together, and having a handful of smart people 
hammer out THE solution, so vendors can take it and start putting it in 
place. And all the while the consumer wins because their only choice is 
in which product to buy, not which standard to support.

Take Care,
mike brothers


----------------------
Michael S. Brothers
Michael.S.Brothers@EMCIns.com
515-362-7473
"I shall walk through the valley of the shadow
of death. On second thought, I shall run through the
valley of the shadow of death, since you get
through the valley quicker that way."



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



From Curt.Arnold at hyprotech.com  Wed Nov 10 16:51:11 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:16:45 2004
Subject: XML Schema and international Booleans
Message-ID: <61DAD58E8F4ED211AC8400A0C9B468734154A7@THOR>

>>Does this mean that I cannot create sub types of boolean which allows
>>other languages  than English?
>>This is neccesary because in Swedish "true"="sant" and "false"="falskt"

Yes, at least currently.

There are a couple of issues here that have shown up in messages on the W3C
Schema comments log such as
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999JulSep/0053.
html and
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999JulSep/0029.
html.

  The first is that both the lexical and value space are inherited when you
create a derived datatype.  This means that you could not, for instance,
have a derived decimal class that accepted numbers with commas as decimal
separators or a derived real class that accepted pi as a valid
representation.  My suggestion was to add a transform element that would
allow you transform the derived datatypes lexical space to the lexical space
of the basetype to something like:

<datatype name="symreal">
	<basetype name="real"/>
	<transform match="pi" replace="3.1415926"/>
	<transform match="e" replace="2.7xxxxxxx"/>
</datatype>

or 

<datatype name="intBoolean">
	<!--  I inherit the boolean data space -->
	<basetype name="boolean"/>
	<!-- match and replace would be regular expression translation,
first matching transform would take precedence -->
	<transform match="0" replace="true"/>	
	<transform match="1" replace="false"/>
	<transform match="sant" replace="true"/>	
	<transform match="falskt" replace="false"/>
</datatype>


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



From duvall at lorien.emufarm.org  Wed Nov 10 17:52:43 1999
From: duvall at lorien.emufarm.org (Danek Duvall)
Date: Mon Jun  7 17:16:46 2004
Subject: `server parsed' XML?
In-Reply-To: <3827D840.6F9318B6@pacbell.net>
References: <199911090630645.SM00172@Unknown.> <A51F7543E295D2118D6600A024CDB2F71B9CA2@MAILPROD> <19991108231247.A13739@lorien.emufarm.org> <Pine.LNX.4.10.9911090953210.2176-100000@localhost.localdom ain> <4.2.0.58.19991109233723.00c9a1b0@203.41.126.17> <19991108231247.A13739@lorien.emufarm.org> <Pine.LNX.4.10.9911090953210.2176-100000@localhost.localdomain> <19991108231247.A13739@lorien.emufarm.org> <3827D840.6F9318B6@pacbell.net>
Message-ID: <19991110095209.A18180@lorien.emufarm.org>

Thanks for all the suggestions!

It turns out that the only option that will work for me is the PI element.
Since our program won't necessarily be running in a browser, we can't count
on javascript, and because we won't always be connecting to a web server,
we can't count on a servlet being available.  Commercial software and stuff
not written in Java is also not an option.

I'm actually currently pre-processing the file with a sed script at
installation time (it's machine name that I'm using, actually not date),
but that's only good once, and you irretrievably lose the semantic meaning
of the template text.

Another possibility is to read the file into a buffer, filter it there, and
then feed the buffer into the XML parser.  But, somehow, that just seems
wrong to me.

Thanks again for the help!

Danek

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 18:51:25 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:46 2004
Subject: Why do we write standards?
In-Reply-To: "Michael S. Brothers"'s message of "Wed, 10 Nov 1999 10:24:38 -0600 (Central Standard Time)"
References: <SIMEON.9911101038.B@PC7155.emcins.com>
Message-ID: <m3d7tip5aq.fsf@localhost.localdomain>

"Michael S. Brothers" <Michael.S.Brothers@EMCIns.Com> writes:

> This thread is fascinating. I liken much of what I have heard to the 
> efforts to standardize HDTV, and if you look at that, it's hard to call 
> standardization anything else but good for consumers.

I doubt that anyone on this list would do so.  I'm a big standards
supporter myself, as I thought I'd made clear in my original posting
(I replied privately to each of those who thought I was attacking
standardization, just to keep noise down on the list).  Perhaps my
subject line confused people a little.

To summarize more briefly, I suggested that there are two paths to
standardization (which we all agree is a good thing):

1. The big-bang approach, where we try to do everything at once and
   either fail or succeed spectacularly.

2. The incremental approach, where we do a little at a time without
   getting too far ahead of implementors.

Both of these head for the same place, but I think that (1) has failed
so often during the 1990s (i.e. every W3C attempt at an HTML standard)
that we should think harder about (2).

I also suggested that there's a cost/benefit cutoff where
standardization no longer makes sense (i.e. it's worthwhile
standardizing the sizes of screws, but probably not their colour or
the number sold in each package).  With the second, incremental
approach, we have a better chance of landing close to that cutoff,
while the big bang approach can easily overshoot it, and usually does.

> Things like TCP/IP and HTTP, which became standards, propelled the
> Web. 

An excellent example for my argument -- the Web standardized IP first,
then TCP, then HTTP.  Imagine if they'd tried to do the whole thing at
once twenty or more years ago!

> Standards are not Socialist, nor are they in the best interest of a 
> consortia, rather are the key to true consumer freedom. 

Oops!  I live in a country (Canada) where "Socialist" is not a dirty
word (they brought us universal health care, after all), and had
forgotten the effect that the example might have on U.S. readers.  For
"Socialist", read "top-down", and for "Libertarian", read "bottom-up".
I think that the ideal path to standardization lies somewhere in the
middle.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 19:01:44 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:46 2004
Subject: Why do we write standards?
References: <000d01bf2b1e$b872ae80$099918d1@docuverse1>
Message-ID: <3829C0DB.DEC7E62C@prescod.net>

Don Park wrote:
> 
> But we are not talking about wild wild west where anything goes.
> We already have the following specs in various states which places,
> imho, sufficient level of constraints in the past and in the future
> to guide the lost and to punish the rebels.

> HTML 4.0 specification
> XHTML 1.0

These specifications *do not apply* to XHTML mixed with other
specifications. They don't say what it means to have a TITLE in a FOOBAR
in a table. They just don't answer the relevant question!

> XHTML 1.1 - Module-based XHTML
> Modularization of XHTML
> Building XHTML Modules

Great. When these specifications are done, we can standardize a
namespace.

> I am as frustrated as a dirt covered sergent in the middle of a
> battlefield who has just been told that he will have to wait for
> the bullets because the manufacturers have standards to consider
> for field inter-operability.

This is the bewildering part Don. You are smarter than to wait for an
HTML namespace in order to use HTML-ish element types. Shoot your damn,
non-standard gun. Build your html-ish applications. Win the war! People
have been doing it for five years. The water is fine. Jump in!

All I ask is that you don't *pretend* that you are doing something
interoperable by sprinkling the magic pixie dust of "namespaces" over
your document type. Without the magic of real, formal standards behind
the dust it's just, well, dust. 

A namespace without a formal definition is not just *useless* -- it is
WORSE THAN USELESS because it encourages the impression of
interoperability without the reality.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
http://www.capitol.state.tx.us/txconst/sections/cn000100-000400.html

"No religious test shall ever be required as a qualification to any
office, or public trust, in this State; nor shall any one be
excluded from holding office on account of his religious sentiments,
provided he acknowledge the existence of a Supreme Being."
                         - Texas Constitution, Article 1, Section 4

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 19:01:44 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:46 2004
Subject: Why do we write standards?
Message-ID: <3829C0C9.EBAF6908@prescod.net>

I so thorougly agree with your post on the costs and benefits of
standards that I cannot see why we disagree on the fundamental point.
It's worth trying again.

> Since we know so little about mixing HTML into other vocabularies
> right now, 

That's arguable, considering the number of HTMLish languages exist, but
let's pretend I agree.

> and since we know almost nothing about how XML will be used
> in Web clients, I think that it makes sense to start by standardizing
> only a little bit.  

I am all for incremental standardization!

> Let's give people a standard Namespace (and the
> name case) and then let them start experimenting 

This is the part I get lost. Namecase interoperability is not
interesting in the least. The only reason it would be interesting is if
we were trying to achieve other types of interoperability. Normalizing
TABLE and Table to the same spelling is only useful if they really ARE
the same thing. If my <TABLE> can contain <TITLE> and <FOOBAR> and your
<Table> can contain <if> and <blink> then they are fundamentally
different and adopting the same namecase does not help.

This is even more the case for name*space* interoperability. We use the
same namespace to say that we are working interoperably. If we are not
(or may not be) working interoperably then why would we use the same
namespace?

It's not about socialism versus libertarinism. It's about adopting a
title like "Democratic Republic of Congo" when there is no democracy to
speak of. 

Namespace equivalent: "Product XYZ supports the XHTML namespace. We use
it in completely different ways than anyone else and our software
crashes with many documents that other people create using XHTML, but we
are XHTML namespace compatible!" What's the damn point?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
http://www.capitol.state.tx.us/txconst/sections/cn000100-000400.html

"No religious test shall ever be required as a qualification to any
office, or public trust, in this State; nor shall any one be
excluded from holding office on account of his religious sentiments,
provided he acknowledge the existence of a Supreme Being."
                         - Texas Constitution, Article 1, Section 4

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 19:08:26 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:46 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
Message-ID: <3829C26E.5A9C6798@prescod.net>

Tim Bray wrote:
> 
> I enjoyed reading that but I have *no* idea what you mean, Len... -T.

Len's posts are koans. Meditate.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Chaos is the Engine" - 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jes at kuantech.com  Wed Nov 10 19:43:28 1999
From: jes at kuantech.com (Jeffrey E. Sussna)
Date: Mon Jun  7 17:16:46 2004
Subject: Worried about Namespaces and Schemas
Message-ID: <000201bf2bb2$fa56aa60$0f36a8c0@quokka.com>

I have been too busy with so-called real work lately to pay much attention
to theretical XML issues. I have, however, been worried by the ongoing
conversation about namespaces and schemas, particularly the implications of
lack of strong connection between them. The only thing I've formally
implemented using XML so far is RDF. RDF does specify a strong connection
between a namespace and a schema. So I am left with the nagging fear that
something is fundamentally and badly broken in XML land, and that it will
bite me hard on the ass. Does anycare to translate the intelligent but not
transparent namespace-schema thread into something I can evaluate without
heavy analysis. I'm usually capable of that level of analysis, but as I said
I'm too busy these days.

TIA,
Jeff Sussna


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



From Chris_Pacetti at whittman-hart.com  Wed Nov 10 19:58:13 1999
From: Chris_Pacetti at whittman-hart.com (Chris_Pacetti@whittman-hart.com)
Date: Mon Jun  7 17:16:46 2004
Subject: unsubscribe
Message-ID: <86256825.006D5295.00@mail.whittman-hart.com>



unsubscribe



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



From murali at ntexchtx.hq.ileaf.com  Wed Nov 10 20:50:32 1999
From: murali at ntexchtx.hq.ileaf.com (Murali)
Date: Mon Jun  7 17:16:46 2004
Subject: external unparsed entities in a XML document
Message-ID: <D06A541E0A87D311950100105AA1D093028902@NTEXCHTX>

Hi

Is it possible to find out the what are the "external unparsed entities" in
an XML document ? 

thanks for your help

Murali Balijepally


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 21:15:32 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:46 2004
Subject: Why do we write standards?
References: <SIMEON.9911101038.B@PC7155.emcins.com> <m3d7tip5aq.fsf@localhost.localdomain>
Message-ID: <3829E06E.67B851DA@prescod.net>

David Megginson wrote:
> 
> To summarize more briefly, I suggested that there are two paths to
> standardization (which we all agree is a good thing):
> 
> 1. The big-bang approach, where we try to do everything at once and
>    either fail or succeed spectacularly.
> 
> 2. The incremental approach, where we do a little at a time without
>    getting too far ahead of implementors.

I think we all agree that in standards, as in code, you must use both.
Incremental when you don't understand the domain and/or don't have time
for the full monty and top-down when you are confident of your
understanding and your success.

My question is: do we give something a label, encourage people to use it
and then later invent it, or do we invent it and then encourage people
to experiment with it, and THEN give it a label? The former does not
strike me as "incremental". Rather, "insane."

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Chaos is the Engine" - 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gkholman at CraneSoftwrights.com  Wed Nov 10 22:36:30 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:16:46 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <3828D62A.5138@hiwaay.net>
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
Message-ID: <4.2.0.58.19991110132052.00d0bf00@pop1.attglobal.net>

At 99/11/09 20:19 -0600, Len Bullard wrote:
>External parsed entities are a done deal for XML 1.0.
>But hey, just a version number, right?  We get to
>have this fight again. :-)
>
>If you and eliot truly think they are bogus and a
>screwup to use, sounds like an issue to me.

I, for one, hope external parsed entities *do not* go away.

While some people may use them incorrectly, why take them away when they 
can be used correctly?

I need them when I need to handle *one* XML file in *many* small manageable 
pieces ... I don't need them for re-use or for sharing, but they provide a 
useful convenience.

.......... Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 10 22:49:11 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:46 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
	 <3828D62A.5138@hiwaay.net> <38298DE0.737E814C@isogen.com>
Message-ID: <3829F64F.3CEBC091@pacbell.net>

Having just been suffering through a DOM implementation
that actually exposes EntityReference nodes, with no way
to turn them off and no utilities to get rid of them,
I'd quite gladly abolish them from DOM ... ;-)

All they seem to be good for in DOM is to trip over, since
any algorithm working on the essential data model for XML
(elements, attributes, text, PIs) needs special casing to
deal with EntityReference nodes (in content or attributes).

Algorithms which are easily expressed in terms of a few
fingers' worth of simple types get very complex when they
need to be updated to address EntityReferences ... and
my own usage happens never to care about such physical
structures.  I just need to see the a logical structure;
details like where data came from at some earlier stage
of processing are a distraction, and a waste of time.

In particular, the notion of readonly children seems to
exist only to prevent applications from manipulating data.
Look but don't touch -- no good when touching is what you
need to do.

That's not specific to _external entities_ ... the problem
exists for all component boundaries that aren't relevant to
the application being developed.  Internal entities have
the problem, as would other kinds of boundaries (using XLink,
SUBDOC, or whatever).

Clearly I'm about to write some code to remove all such
noise from any DOM that tries to inflict it on me!!

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lauren at sqwest.bc.ca  Wed Nov 10 23:10:03 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:16:46 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <3829F64F.3CEBC091@pacbell.net>
Message-ID: <199911102307.PAA26015@mail.sqwest.bc.ca>

On 10 Nov 99, at 14:48, David Brownell wrote:

> Having just been suffering through a DOM implementation
> that actually exposes EntityReference nodes, with no way
> to turn them off and no utilities to get rid of them,
> I'd quite gladly abolish them from DOM ... ;-)

Well, you can always implement TreeWalker (part of the Level 2 
Traversal module), which has as its first use case how to navigate 
the tree without seeing entity reference nodes. Not that I disagree 
that tripping over them can be a pain, but there is now a DOM way 
of not doing so.


Lauren

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 10 23:48:21 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:16:46 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
 <3828D62A.5138@hiwaay.net>
Message-ID: <38298DE0.737E814C@isogen.com>

Len Bullard wrote:
> 
> Tim Bray wrote:
> >
> > At 06:30 PM 11/9/99 -0600, Len Bullard wrote:
> > >We can't bag the cat once it is in the alley
> > >unless we are faster than the cat, or know where it sleeps.  In either
> > >case, we will have a mad cat when we take it out of the bag.
> >
> > I enjoyed reading that but I have *no* idea what you mean, Len... -T
> 
> External parsed entities are a done deal for XML 1.0.
> But hey, just a version number, right?  We get to
> have this fight again. :-)
> 
> If you and eliot truly think they are bogus and a
> screwup to use, sounds like an issue to me.
> 
> How do subdocs fix this problem, Eliot?  Or
> better, what problems do subdocs fix for markup systems?

By "subdocs" I presume you mean the use of separate documents to define
a single logical "compound" document (the SGML concept of "subdoc" is in
fact a red herring--what's important is the use of separate documents,
not the fact that they are declared as SUBDOC entities--thus the lack of
SUBDOC in XML is absolutely no loss). It solves the problem by forcing
you to use and manage truly reusable objects, rather than justing doing
syntactic copy and paste through the inclusion of external parsed
entities. 

It also forces you to recognize that all use-by-reference needs to occur
at the semantic (DOM, grove) level, not the syntactic level. Once you
realize that, all sorts of apparently hard problems or non-sensical
cases become easy and quite sensical, because we are out of the
syntactic domain and into the semantic domain. For example, it is
non-sensical for one element to be replaced by another element in
another document at the syntactic level (parse time), but it is
perfectly sensical for an element node to redirect to another element
node in another DOM and the processing needed to achieve this is
trivial:

# See if node is a redirection and resolve it:
try node.atts["redir"]:
   pointer = node.atts["redir"].value
   node = xpath.resolve_pointer_to_node(pointer)
except IndexError:
   # No redir attribute, just go on as before

It couldn't be easier at this level. All that's required is that your
processing software understand the semantics of the documents that might
be pulled together this way, which might of course use different
document types, but that's no different from needing to understand a
document that uses elements with different namespace prefixes, so it's a
constant part of the XML processing problem and this approach doesn't
change it (except to possibly make it both more obvious that the problem
exists and clearer as to how you define a framework for handling the
case).

The problem with external parsed entities is that they are not true
objects in the sense that they have no independent existence outside the
contexts in which they are used--they cannot be parsed or validated in
isolation and must conform *syntactically* to all the contexts they are
used. Thus the problems with ID conflict, entity names, etc. When using
multiple documents, each element maintains its original document context
and therefore its fundamental identity, so there is no possibility of ID
or name conflict and you can always examine the element in its original
context as well as in any contexts in which it might be used.

Of course, if you want to write a transform that generates a new single
instance as output, you have to disambiguat the names and IDs, but
there's no programming difficulty there, it's just an exercise in
rewriting of pointers and, possibly, applying name-space prefixes to
element type names (if you're so inclined). But this is only one way to
take advantage of semantic use-by-reference--you should never assume
that the processing result of compound document processing is another
XML document. Using GroveMinder we have a grove-aware browser that does
all this resolution dynamically at run-time, generating HTML as output.
There's nothing particularly difficult or inventive about this except
that we did it (and that it happens to implement the part of the HyTime
standard that deals with use-by-reference, the value reference
facility).

Note also that if, for example, XLink made a clear distinction between
use-by-reference relationships and hyperlink relationships, that it
would be clearer how one can have a highly-generic, standards-based
infrastructure for doing this stuff.  As it is, you can define your own
conventions for using XLinks to mean use by reference (the "show=embed"
part of XLink is almost there, but it is not sufficiently flexible. For
example, it doesn't let you define the value of an attribute by
reference, which is quite useful, if not a hard requirement for certain
problems).

By using independent documents you get objects (documents) that have
their own independent existence. They can be reliably re-used because
they are combined with other documents *semantically*, not
syntactically, at the processing level. That is, I construct a bunch of
DOM trees (or groves) and then another layer of processing decides how
to use them together. No document directly interfers with any other. Of
course, there will be dependencies between the documents, such as one
document linking to something in another document.

Because the processing of compound documents is a separate layer, there
can be many different ways of processing the same compound document and
therefore different sets of constraints that you might want to enforce.
You can have a policy that says all the members of the document must
have the same DTD or maybe you don't care because your processing isn't
DTD sensitive (e.g., a generic XML structure browser). The system can be
more or less sophisticated depending on your requirements. You don't
have to do twisted things like use name spaces to disambiguate element
type names in the source documents or rationalize all the documents to a
single over-arching document type. Individual documents can be optimized
for their own local purposes and still combined together meaningfully
with other documents, given some rules for playing nice together (e.g.,
Architectures, architypes, etc.).

Once you've built the infrastructure to handle this way of doing things,
the range of problems you can solve and the range of requirements you
support increases dramatically and the incremental cost of the system
drops rapidly.

I note that tools like Framemaker and Wordperfect (and I think even
Word) have *always* worked this way. In Framemaker, for example, a
"book" is composed of multiple documents. Each document is completely
syntactically independent of the other documents in the book: it can
have its own templates, customizations, etc. The addressing between
documents for cross references and hyperlinks is document-to-document
addressing because each document establishes its own ID name space in
Framemaker. There is no syntactic interference between different
documents in the same book.  [NOTE: this is not true for the SGML
version of Framemaker--for whatever reason, the designers chose not to
carry this model into the SGML version, which they could have done very
easily.]

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From burton at relativity.yi.org  Wed Nov 10 23:58:01 1999
From: burton at relativity.yi.org (Kevin A. Burton)
Date: Mon Jun  7 17:16:46 2004
Subject: DOM -> SQL -> DOM: Serialization...
Message-ID: <382A92C1.BF5DEF25@relativity.yi.org>

I need to take a ton of XML documents... about say 100M and run analysis
on them in realtime.  (less than 1 second)

I am planning on using a parser to return a DOM, then take that DOM and
Serialize it to SQL with maybe ENTITY|ATTRIBUTE|CDATA tables, etc.  And
then write an interface (maybe XMLQL) to get the data.

Has anyone seen an Open Source project to do this?

Kevin

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 03:12:16 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:46 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca> <4.2.0.58.19991110132052.00d0bf00@pop1.attglobal.net>
Message-ID: <382A2998.79D6@hiwaay.net>

G. Ken Holman wrote:

> I, for one, hope external parsed entities *do not* go away.
> 
> While some people may use them incorrectly, why take them away when they
> can be used correctly?
> 
> I need them when I need to handle *one* XML file in *many* small manageable
> pieces ... I don't need them for re-use or for sharing, but they provide a
> useful convenience.

Cost questions:  does the feature 

1.  Add cost to implementation?
2.  Add complexity to information handling 

Are there alternatives that get the same result?
How do these alternatives affect the costs?
As you are a real pro who has worked with most 
of the major SGML and XML systems, is the 
convenience worth the overhead?

I've used them but not as much since I began 
to generate the markup server side.  Yes, 
they are good for managing small chunks of big 
documents and easy to assemble with tools if one 
is careful in building the entities, and knows how one is  
going to use them with other chunks.  Most of 
the time now, given the state of cheap tools, 
I use the relational DB for that.  General 
entities *feel* like batch SGML.  I'm not 
convinced they should go away because we 
have them, the cat is in the bag.  Why make 
the cat mad?  On the other hand, others 
can hold that bag because they don't add 
much to a server side repetoire, AFAICT.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 11 04:21:19 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:46 2004
Subject: XML Schema and international Booleans
Message-ID: <001601bf2bff$77a1cad0$1bf96d8c@NT.JELLIFFE.COM.AU>

 From: Anders W. Tell <anderst@toolsmiths.se>

 >Does this mean that I cannot create sub types of boolean which allows
>other languages  than English?

I think the XML Schema WG is working under the rationale that the only
reliable approach is to standardize only a single way to do any one
thing. So there are only Gregorian dates using ISO 8601, and there is
only one form of ISO8601 used, for example.

There has been a lot of debate about this between the W3C
internationalization group, of course.  The issue comes down to whether
to provide localization or internationalization.  I think, for XML
schema, the non-localized approach (which is code for "English"--how
shocking)  can be justified.

Since, I think, XML Schemas is fundamentally intended for systems with
something like Java at one end and something like SQL at the other, the
reasons for localization are perhaps less than otherwise.  I think there
is an assumption that input will go through something like a complex
forms mechanism and output will go through something like XSL.

For controlled vocabularies, I suspect the better way to handle them is
to have a Swedish->English  XSL script on the client.  There are
thousands of languages, and I don't think it is reasonable to expect
implementers to implement them.  And it is dangerous to have standards
made using words that the editors could not read.

I am sure any ideas are welcome.  One approach would be to allow the
schema developer to put in aliases for keywords.  Another approach would
be to define entities &sant; and &falskt;  but then you would also need
a DTD. Oops.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 11 04:41:45 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:47 2004
Subject: XML 2.0alpha specification released! (Re: external parsed entites (was: A unique ID question ?))
Message-ID: <003701bf2c02$52861960$1bf96d8c@NT.JELLIFFE.COM.AU>


From: W. Eliot Kimber <eliot@isogen.com>

 >> External parsed entities are a done deal for XML 1.0.
>> But hey, just a version number, right?  We get to
>> have this fight again. :-)

I am happy to announce the release of the XML 2.0alpha specification. It
has been created by using all the criticisms of XML over the last year.
A non-exhaustive list of its main features compared to XML 1.0 is that
it:

    * only use UTF-8 (e.g. some W3C people) and so get rid of the
encoding header, numeric character references
    * get rid of PIs (e.g. TimB-L)
    * get rid of parameter entities (e.g., some schema people)
    * get rid of DTDs (e.g. many of the same people)
    * get rid of notations  (since no-one knows what they are for still)
    * get rid of entities (since XLink will replace them)
    * gets rid of  the ' as a literal delimiter
    * get rid of attributes (since all we need are elements)
    * get rid of IDs (since local names are old hat)
    * get rid of PUBLIC identifiers (since everything should be a URI)
    * get rid of CDATA sections (since they make grepping unsafe)
    * get rid of using the name of an element to key its type (i.e. you
have to use a namespace URI and the munged name)
    * get rid of elements and embedded markup (e.g. Ted Nelson)
    * get rid of chunks of Unicode through "early normalization" (e.g.,
the W3C I18n WG)
    * because the only delimiter is the comment delimiter, the need for
&amp; and &gt; is removed; because the string <!-- can be represented as
<!<@-- -->-- there is no need for &lt; either.

This gives us quite a nice markup language: XML 2.0alpha which consists
of only
    * data
    * comments, at user option

I propose that we should all spend the next 100 years discussing this,
and that every W3C specification in the mean time should try to
influence the outcome by supporting only the subset of XML 1.0 they
like, until concensus is reached by people outside the original
developers of XML.

Indeed, wise implementors should delay until XML 3.0.  There is talk
that allowing all these characters poses internationalization problems,
so it is possible that only ASCII characters may be used in the future.
Because of WAI reason, it may be that only visually distinct characters
may be allowed: so XML 3.0 will only consist of one or more occurrences
letters O and X.  This will provide substantial benefits for compression
and binary representation, as well as direct representation of certain
games.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From pmandgi at hotmail.com  Thu Nov 11 05:10:48 1999
From: pmandgi at hotmail.com (Prakash Mandgi)
Date: Mon Jun  7 17:16:47 2004
Subject: DOM -> SQL -> DOM: Serialization...
References: <382A92C1.BF5DEF25@relativity.yi.org>
Message-ID: <19991111051014.78338.qmail@hotmail.com>

Hi Kevin

with sql server / oracle i doubt you can retrieve that data so fast
especially over
the network let alone parse it.
You may want to consider using Object databases
1) Persist DOM documents as is in an object database and then run XQL /
XPath etc
2) Use entity java beans to store the DOM document in memory

You can pretty much forget about serializing / deserializing DOM documents
of that size in less than a second.

Prakash

----- Original Message -----
From: Kevin A. Burton <burton@relativity.yi.org>
To: <xml-dev@ic.ac.uk>; <cocoon@list.working-dogs.com>
Sent: Thursday, November 11, 1999 4:56 AM
Subject: DOM -> SQL -> DOM: Serialization...


> I need to take a ton of XML documents... about say 100M and run analysis
> on them in realtime.  (less than 1 second)
>
> I am planning on using a parser to return a DOM, then take that DOM and
> Serialize it to SQL with maybe ENTITY|ATTRIBUTE|CDATA tables, etc.  And
> then write an interface (maybe XMLQL) to get the data.
>
> Has anyone seen an Open Source project to do this?
>
> Kevin
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 11 06:03:23 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:47 2004
Subject: Why do we write standards?
In-Reply-To: <3829C0DB.DEC7E62C@prescod.net>
Message-ID: <000801bf2bf3$24d5c560$099918d1@docuverse1>

Paul Prescod wrote:
>> HTML 4.0 specification
>> XHTML 1.0
>
>These specifications *do not apply* to XHTML mixed with other
>specifications. They don't say what it means to have a TITLE 
>in a FOOBAR in a table. They just don't answer the relevant question!

On the contrary, I can not see how anyone who reads the TITLE element
section of the HTML 4.0 spec can decide to use it inside anything
other than the HEAD element.  If the designer wants to reuse the
tag name 'title' then he should not be using the HTML namespace for
the TITLE tag.

>> XHTML 1.1 - Module-based XHTML
>> Modularization of XHTML
>> Building XHTML Modules
>
>Great. When these specifications are done, we can standardize a
>namespace.

While these specs are not done yet, they are already a great
resource for those trying to design composite documents.  Many
knowledgable folks have spent a great deal of effort writing these
specs and I totally disagree with the position that these specs
are worth nothing until it reaches Recommendation status.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abisheks at india.hp.com  Thu Nov 11 06:50:58 1999
From: abisheks at india.hp.com (Abhishek Srivastava)
Date: Mon Jun  7 17:16:47 2004
Subject: Standards/guide lines for creating XML Documents
Message-ID: <014301bf2c10$e34286b0$252f0a0f@india.hp.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Abhishek Srivastava.vcf
Type: text/x-vcard
Size: 1561 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991111/01895ccb/AbhishekSrivastava.vcf
From donpark at docuverse.com  Thu Nov 11 07:12:10 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:47 2004
Subject: XML 2.0alpha specification released! (Re: external parsed entites (was: A unique ID question ?))
In-Reply-To: <003701bf2c02$52861960$1bf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000401bf2c14$51898bc0$099918d1@docuverse1>

Lets get rid of data too since all it does is make us work.

We'll be left with just comments so we can just rename the spec XML-DEV 1.0.

<g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sb at metis.no  Thu Nov 11 09:01:33 1999
From: sb at metis.no (Steinar Bang)
Date: Mon Jun  7 17:16:47 2004
Subject: no startElement in Xerxes C++ SAX DocumentHandler
Message-ID: <whhfitcsgp.fsf@viffer.oslo.metis.no>

The DocumentHandler of the Xerxes C++ SAX implementation doesn't seem
to have a startElement() function
        http://xml.apache.org/xerces-c/apiDocs/XMLDocumentHandler.html

Is this a bug in the documentation, or a feature of this
DocumentHandler, I wonder?

I would have sent this to the Xerces mailing list, but I was unable to 
find its address listed here:
        http://xml.apache.org/xerces-c/feedback.html

(I'm also noting that this seems like the IBM C++ XML parser SAX,
which I doesn't like much...:-/ )

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



From xmldev at decisionsoft.com  Thu Nov 11 09:33:10 1999
From: xmldev at decisionsoft.com (Michael Mason)
Date: Mon Jun  7 17:16:47 2004
Subject: no startElement in Xerxes C++ SAX DocumentHandler
References: <whhfitcsgp.fsf@viffer.oslo.metis.no>
Message-ID: <382A8D15.19DA54D9@decisionsoft.com>

Steinar Bang wrote:

> The DocumentHandler of the Xerxes C++ SAX implementation doesn't seem
> to have a startElement() function
>         http://xml.apache.org/xerces-c/apiDocs/XMLDocumentHandler.html
> 
> Is this a bug in the documentation, or a feature of this
> DocumentHandler, I wonder?

Bug in the docs -- it should certainly be there.

> I would have sent this to the Xerces mailing list, but I was unable to
> find its address listed here:
>         http://xml.apache.org/xerces-c/feedback.html

You want http://xml.apache.org/mail.html

> (I'm also noting that this seems like the IBM C++ XML parser SAX,
> which I doesn't like much...:-/ )

It *is* the IBM XML4C stuff -- IBM have donated it to the Apache
project. Hence I'm still using the documentation from IBM, since the
Apache stuff isn't quite there yet (empty directory?).

Mike.

-- 
Mike Mason, Software Engineer
XML Script Development Team                    Office: 44-1865-203192
http://www.xmlscript.org/                      Mobile: 44-7050-288923

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 09:44:07 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:47 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <199911102307.PAA26015@mail.sqwest.bc.ca>
Message-ID: <382A8FE3.51D9788E@pacbell.net>

Lauren Wood wrote:
> 
> On 10 Nov 99, at 14:48, David Brownell wrote:
> 
> > Having just been suffering through a DOM implementation
> > that actually exposes EntityReference nodes, with no way
> > to turn them off and no utilities to get rid of them,
> > I'd quite gladly abolish them from DOM ... ;-)
> 
> Well, you can always implement TreeWalker (part of the Level 2
> Traversal module), which has as its first use case how to navigate
> the tree without seeing entity reference nodes. Not that I disagree
> that tripping over them can be a pain, but there is now a DOM way
> of not doing so.

I was thinking of that as I wrote, in fact.  But the TreeWalker
is still a "look but don't touch" model ... the children of
an entity ref are still going to be readonly, even if the walker
masks the EntityReference from your sight.  Solutions addressing
the "I need to touch it!" aspect can't use just TreeWalker.

Perhaps the general issue is that whenever DOM starts to offer
APIs for populating a DOM Document, there need to be options
about what features should be exposed.  For my usage, things
like EntityReference and CDATASection (vs normal Text) would
hardly ever be used.

Or perhaps there should be variants of Element.normalize() that
give you other options for getting rid of extra tree nodes.
"No adjacent text nodes" is covered.  How about flags for cases
like "don't use EntityReference", "don't use CDATASection",
and "don't use Comment"?

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From anderst at toolsmiths.se  Thu Nov 11 10:00:39 1999
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:16:47 2004
Subject: XML Schema and international Booleans
References: <001601bf2bff$77a1cad0$1bf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <382A0CE1.E4CF7C1E@toolsmiths.se>

Rick Jelliffe wrote:

>  From: Anders W. Tell <anderst@toolsmiths.se>
>
>  >Does this mean that I cannot create sub types of boolean which allows
> >other languages  than English?
>
> I think the XML Schema WG is working under the rationale that the only
> reliable approach is to standardize only a single way to do any one
> thing.

Then I have a hard time to understand why they are using highly flexible value-space,
lexical-representation concepts and then don't use them, as in the case of boolean.

> So there are only Gregorian dates using ISO 8601, and there is
> only one form of ISO8601 used, for example.

ISO creates international standards and im pretty sure that {true,false} is not
internationally accepted. Using zero (0) and one (1) is certainly more neutral and
logical.

Why not formulate a concept of "normalized" or "canonical" internationally accepted
lexical representation, and expand the definition/use of the lexical rules in order to
allow language variants.

>
> There has been a lot of debate about this between the W3C
> internationalization group, of course.  The issue comes down to whether
> to provide localization or internationalization.  I think, for XML
> schema, the non-localized approach (which is code for "English"--how
> shocking)  can be justified.

Frankly Im surprised that it appears that Internationalization is not accepted
by all parties involved in writing and debating international standards.
A "non-localized" schema version (XML Schema document) is OK however
if the use of english language is mandatory in parts of actual XML documents then
its a little to much anglosaxian cultural imperialism ;) for me.
Seriously, IMHO,XML Schema is *the place* to standardize Internationalization variations.

>
> Since, I think, XML Schemas is fundamentally intended for systems with
> something like Java at one end and something like SQL at the other, the
> reasons for localization are perhaps less than otherwise.  I think there
> is an assumption that input will go through something like a complex
> forms mechanism and output will go through something like XSL.

I don't think all applications will use complex software as XSL for a number
of reasons, space, complexity, time to implement etc.

>
> For controlled vocabularies, I suspect the better way to handle them is
> to have a Swedish->English  XSL script on the client.  There are
> thousands of languages, and I don't think it is reasonable to expect
> implementers to implement them.

And why should I be forced to use english as a norm ? Why not Swedish
or Esperanto, which is supposed to be the most universal language of them all.

Actually I heard a month ago that a Swedish university teacher (language department)
claimed that Swedish is the "closest to all other languages" language. Which
should indicate, if the person is right, that Swedish should be used as Norm
instead of English. Just a rumor i overheard ;)

> And it is dangerous to have standards
> made using words that the editors could not read.

Im not sure I follow you here. A human editor understand the words in the language/s
the person understands, a computer application editor (user agent) understands the
words in the schema,from which the xml elements are created from, supports.

>
> I am sure any ideas are welcome.  One approach would be to allow the
> schema developer to put in aliases for keywords.  Another approach would
> be to define entities &sant; and &falskt;  but then you would also need
> a DTD. Oops.

An idea would be something like this:
------------------------------------------
Define value space as: {binary logical false, binary logical true}
  (expressed in english since the spec is written currently only in English,
   the swedish spec. version would read: {bin?rt logiskt falskt, bin?rt logiskt sant})

Define zero ("0") and one ("1") as normalized lexical representation.

Add a enumeration's bindings concept:
 sequence of pairs of valuespace expression and lexical representation
 where each valuespace expression must express a subspace (or equal) of the
 value space.
  <enumeration-binding>
     <bind><value> true <value>  <literal> sant </literal> </bind>
     <bind><value> falskt <value>  <literal> falskt </literal> </bind>
     <bind><value> true <value>  <literal> on </literal> </bind>
     <bind><value> falskt <value>  <literal> off </literal> </bind>
     <bind><value> true <value>  <literal> oui </literal> </bind>
     <bind><value> falskt <value>  <literal> no </literal> </bind>
     <bind><value> true <value>  <literal> yes </literal> </bind>
     <bind><value> falskt <value>  <literal> no </literal> </bind>

     <bind><value> true <value>  <pattern> [Tt][Rr][Ue][Ee]</pattern> </bind>
     <bind><value> falskt <value>  <pattern> [Ff][Aa][Ll][Ss][Ee] </pattern> </bind>
  </enumeration-binding>

Med v?nlig h?lsning
/anders
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/  Financial Toolsmiths AB  /
/  Anders W. Tell           /
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



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



From vikas at adithya.ncb.ernet.in  Thu Nov 11 10:00:22 1999
From: vikas at adithya.ncb.ernet.in (vikas jaitly)
Date: Mon Jun  7 17:16:47 2004
Subject: XML Support for Software Agents
Message-ID: <006c01bf2c2c$d5174b40$937d29ca@sni07.ncb.ernet.in>

Hi ,

        Can XML be used as an inter-agent communication language. Is there any support site for this type of information ?

Thanx,
Vikas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991111/72a1468f/attachment.htm
From Andy.Bradbury at syntegra.bt.co.uk  Thu Nov 11 12:48:12 1999
From: Andy.Bradbury at syntegra.bt.co.uk (Andy.Bradbury@syntegra.bt.co.uk)
Date: Mon Jun  7 17:16:47 2004
Subject: external unparsed entities in a XML document
Message-ID: <65AF45D5E535D2118AFB0008C7FA23180C3E3F@FL-EXCHANGE-03>

Murali

Since no-one else seems to be picking up on this, an "external unparsed
entity" is a storage object (file) which is referenced for inclusion in an
XML document but which, since it is external to that document, doesn't get
parsed when the host is parsed.

Hope this helps

Regards

Andy B.

-----Original Message-----
From: Murali [mailto:murali@ntexchtx.hq.ileaf.com]
Sent: 10 November 1999 20:54
To: xml-dev@ic.ac.uk
Subject: external unparsed entities in a XML document


Hi

Is it possible to find out the what are the "external unparsed entities" in
an XML document ? 

thanks for your help

Murali Balijepally


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 11 13:47:02 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:47 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <000201bf2c4b$6a56b560$099918d1@docuverse1>

Everyone,

I have been thinking that there are applications out there that
can benefit from using XML yet donot need all of its features.
The Canonical XML spec goes quite a distance in cutting away
some of the features, for different purpose, but I still feel
that more can be cut away.  Rick Jelliffe's rather funny
message along with some WebDAV papers I read over the weekend
got my mind buzzing enough for me to share this idea with the
rest of XML-DEV.

What I have in mind is a subset of XML, I'll call it Simple
(or Stupid) Markup Language (SML) for now, that simplifies XML
down to the bare essentials.  Ideally, it should also be a
subset of Canonical XML.  Here are some ideas:

o No Attributes (ouch!)
o No PI, Comments, Notations, or CDATA sections
o No document type declaration
o UTF-8 encoding only
o No non-character entity references
o No predefined character entities (I am iffy on this one)

What do you guys think?  Please do not get caught up with
the list I presented above because they are just ideas and
subject to change later depending on your capacity to scream
convincingly.  The key point to consider is whether there is
a broad enough need for such a subset of XML.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 13:54:10 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:16:47 2004
Subject: Offtopic : Eclectic weblog
Message-ID: <000f01bf2c4c$12a800c0$ab20268a@pc-lrd.bath.ac.uk>

Hi,

This is offtopic, but if any of you were (I know one or 
two people were) reading my attempts at a summary style weblog for XML-DEV 
(called Eclectic, hosted at my.userland.com, link at the bottom of 
this mail) I'd just like to say that I *am* still updating it, 
despite what the URL is currently displaying.

I last updated this morning, and not several weeks ago as 
it claims. I hope to iron the glitches out soon.

Cheers,

L.


==================================================================
    "Never Do With More, What Can Be Achieved With Less"
				---William of Occam
==================================================================
Leigh Dodds                             Eml:  ldodds@ingenta.com
ingenta ltd                             Tel:  +44 1225 826619
BUCS Building, University of Bath       Fax:  +44 1225 826283

HomePage :				 	http://www.bath.ac.uk/~ccslrd/
WebLog   :			   http://my.userland.com/viewChannel$1079
==================================================================


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 14:20:51 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:16:47 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <001201bf2c4f$bf63f1e0$ab20268a@pc-lrd.bath.ac.uk>

> What I have in mind is a subset of XML, I'll call it Simple
> (or Stupid) Markup Language (SML) for now, that simplifies XML
> down to the bare essentials.  

...snip!...

>The key point to consider is whether there is
> a broad enough need for such a subset of XML.

What would we gain from SML that we couldn't gain from only 
producing (and therefore processing) XML documents but 
without any of the 'additional' features?

If I don't want to have attributes, or PIs, or use entities, 
etc. then I don't *have* to. Granted the SAX/DOM APIs 
still provide support for these constructs, but 
I can still ignore them surely? (and I still retain 
the option to use them at a later date).

Thats assuming that I've got total control over both 
the system and the documents. If I haven't got control over the 
documents/fragments/whatever, then my system will have to assume it 
receives XML, just in case it does.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Thu Nov 11 14:50:54 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:48 2004
Subject: Feeler for SML (Simple Markup Language)
References: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <004601bf2c53$b95b4f60$46d18dce@PTGRESTON>


----- Original Message -----
From: Don Park <donpark@docuverse.com>
To: <xml-dev@ic.ac.uk>
Sent: Thursday, November 11, 1999 8:48 AM
Subject: Feeler for SML (Simple Markup Language)


> I have been thinking that there are applications out there that
> can benefit from using XML yet do not need all of its features.

>Here are some ideas:
>
> o No Attributes (ouch!)
> o No PI, Comments, Notations, or CDATA sections
> o No document type declaration
> o UTF-8 encoding only
> o No non-character entity references
> o No predefined character entities (I am iffy on this one)
>
> What do you guys think?

I'm interested!  I was advocating a stripped-down "minimal DOM" early last
year, and the decision was to wait until somebody defined a stripped-down
XML (which I guess was not exactly what the Canonical XML people ended up
doing).

I'd have to say that with the explosion of interest in using XML in
ultra-light clients such as cellphones and high transaction volume
server-side applications such as enterprise messaging, there *should* be a
lot of interest in defining standard subsets of XML and the various APIs
designed to maximize processing efficiency.  These are areas of obvious
interest to my employer, and I'm pretty sure I could get time authorized to
work on such a thing.

I've had some correspondence with other interested parties ... the sticking
point is where to do this?  The W3C doesn't appear to be interested ... The
Java Community Process is obviously focussed on Java, but one can easily
imagine that many "SML" processors are going to be written in C or
Assembler, so those requirements ought to be designed in from the beginning
... The IETF process (as I understand it, correct me but let's not have a
flame war if you disagree) would take too long to get such a thing out in
time to be useful in today's extremely fast-moving environment .... It might
be interesting to see if an ad-hoc group like the one that defined SAX could
do such a thing, but the xml-dev community is much larger (and probably more
unwieldy) than it was a couple of years ago ...

Any ideas?

Mike Chamion


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



From dhunter at Mobility.com  Thu Nov 11 14:52:54 1999
From: dhunter at Mobility.com (Hunter, David)
Date: Mon Jun  7 17:16:48 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <805C62F55FFAD1118D0800805FBB428D02BC00A1@cc20exch2.mobility.com>

<snip/>

Perhaps from the point of view of a parser writer, this might be a good
thing.  If you knew you were never going to need these constructs, you could
build a smaller, faster parser.

>From the point of view of applications that use XML, however, SML would not
provide much gain, except perhaps the slight speed advantage of using one of
these stripped down, souped up parsers; as Leigh Dodds pointed out, you
could just use XML without the features you don't need.

So the two points to consider:
-are the speed advantages of one of these SML parsers significant over an
XML parser?
-with XML parsers [hopefully] becoming ubiquitous in most systems, are
people really going to use SML and SML parsers, when they can just use XML?

David Hunter
david.hunter@mobileq.com
http://www.MobileQ.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From murali at ntexchtx.hq.ileaf.com  Thu Nov 11 14:55:45 1999
From: murali at ntexchtx.hq.ileaf.com (Murali)
Date: Mon Jun  7 17:16:48 2004
Subject: external unparsed entities in a XML document
Message-ID: <D06A541E0A87D311950100105AA1D093028903@NTEXCHTX>

Hi Philip

I think i did not put properly my question. 
What i want to know is when i am parsing the XML document ( either using DOM
api or 
SAX api ) is it possible to find out what subset of external entities
defined in the DTD
are used in the XML document? 
e.g., In the SAX api, there is a listener called "Entityresolver" ( which
will be called 
when parser encounters either parsed or unparsed external entities). But it
looks like this
method is not getting called for the "external unparsed" entites.

thanks for you help.
Murali
-----Original Message-----
From: Philip Nye [mailto:philipnye@freenet.co.uk]
Sent: Thursday, November 11, 1999 8:22 AM
To: Murali
Subject: Re: external unparsed entities in a XML document


> Is it possible to find out the what are the "external unparsed entities"
in
> an XML document ?

Yes it is but it is quite hard to find all the pieces in the XML 1.0
Spec.

External unparsed entities are values which attributes may take. Look at
sections 4, 4.2.2 and 3.3 and production [56] for a start.

e.g. Usage looks something like this.

In the DTD

<!NOTATION someNotation PUBLIC "notationIdentifier" >
<!ENTITY EUEinstance SYSTEM "whereToGetItFrom" NDATA someNotation >
<!ELEMENT anElement EMPTY >
<!ATTLIST anElement entityAttribute ENTITY>

then in the document

<anElement entityAttribute="EUEinstance" />


Philip Nye
-- 
Philip Nye
Engineering Arts
72 Herberton Road  ~  Bournemouth  BH6 5HZ  ~  UK
tel +44 (0)1202 418236  ~  fax +44 (0)1202 418676
mailto:philipnye@freenet.co.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Thu Nov 11 15:00:24 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:48 2004
Subject: Feeler for SML (Simple Markup Language)
References: <001201bf2c4f$bf63f1e0$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <005201bf2c55$10bb5ce0$46d18dce@PTGRESTON>


----- Original Message -----
From: Leigh Dodds <ldodds@ingenta.com>
To: xml-dev <xml-dev@ic.ac.uk>
Sent: Thursday, November 11, 1999 9:19 AM
Subject: RE: Feeler for SML (Simple Markup Language)



> What would we gain from SML that we couldn't gain from only
> producing (and therefore processing) XML documents but
> without any of the 'additional' features?

A "standard", or really a sortof an informal contract, saying I won't send
you messages or documents with any attributes, PIs, entities, etc.
This lets you optimize your code to be blissfully ignorant of them.  But
without
a "contract" saying what we won't send each other, there are many potentials
for interoperability failures.  I might send Don a document with attributes
(which
I happen to like) but his processor chokes on. It would be better to form
a wide consensus on EXACTLY what subset of XML the "SML community" would
understand.

>
> If I don't want to have attributes, or PIs, or use entities,
> etc. then I don't *have* to. Granted the SAX/DOM APIs
> still provide support for these constructs, but
> I can still ignore them surely? (and I still retain
> the option to use them at a later date).

Right.  But your true-XML parser, DOM/SAX APIs, transformation
engines, etc. will be bloated with all sorts of code that will never be
executed.  If I'm writing applications for cellphones, that matters!





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 15:27:54 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:16:48 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <005201bf2c55$10bb5ce0$46d18dce@PTGRESTON>
Message-ID: <001b01bf2c59$1be27280$ab20268a@pc-lrd.bath.ac.uk>

> A "standard", or really a sortof an informal contract, saying I won't send
> you messages or documents with any attributes, PIs, entities, etc.
> This lets you optimize your code to be blissfully ignorant of them.  But
> without a "contract" saying what we won't send each other, there are many
> potentials> for interoperability failures.  I might send Don a document
with
> attributes (which I happen to like) but his processor chokes on. It would
be
> better to form a wide consensus on EXACTLY what subset of XML the "SML
community"
> would understand.

Well isn't your contract between your and Dons processors going to be
the 'protocol' for your application. Can't that protocol just say
"We're using XML, but without any attributes, and...". You've still got
to define the message formats so define them without recourse
to PIs, entities, attributes, etc, etc.

> Right.  But your true-XML parser, DOM/SAX APIs, transformation
> engines, etc. will be bloated with all sorts of code that will never be
> executed.  If I'm writing applications for cellphones, that matters!

Granted. Although if my cellphone is running a Java VM and is downloading
code as it goes, then I only need to download the PI/entity/attribute
handler code as needed. So the bloat could be mitigated.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gkholman at CraneSoftwrights.com  Thu Nov 11 15:31:44 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:16:48 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <382A2998.79D6@hiwaay.net>
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
 <4.2.0.58.19991110132052.00d0bf00@pop1.attglobal.net>
Message-ID: <4.2.0.58.19991111101704.00b58830@pop1.attglobal.net>

At 99/11/10 23:27 -0600, Len Bullard wrote:
>G. Ken Holman wrote:
> > I need them when I need to handle *one* XML file in *many* small manageable
> > pieces ... I don't need them for re-use or for sharing, but they provide a
> > useful convenience.
>
>Cost questions:  does the feature
>
>1.  Add cost to implementation?

I haven't written an XML processor, so I can't comment on that.

>2.  Add complexity to information handling

No, it simplifies the handling of my information by allowing me to handle a 
large file in small chunks.

My XSLT/XPath book is written in XML.  For downstream processing of the PDF 
it needs to be one large contiguous instance.

For editing, I have every individual lesson (each between one and 10 frames 
in length) in individual external parsed entities.  The entirety is over 
300 printed pages ... I don't want to pull all of that into my editor to 
work on a single lesson.

>is the
>convenience worth the overhead?

The convenience is worth a lot to me.

>Yes,
>they are good for managing small chunks of big
>documents and easy to assemble with tools if one
>is careful in building the entities,

True, but they do enforce correct logical boundaries within physical 
containers, so I see that not a lot of care is needed ... I think they are 
pretty easy to use.

>and knows how one is
>going to use them with other chunks.

Ahhhhhh!  But I don't use them that way.  They aren't designed for reuse.

When I want one of my presentations to use a lesson from another 
presentation, I address that lesson by name and refer to the presentation 
by URI and my assembly process goes and fetches the lesson out of that 
other completely parsed instance at production time.  I'm fetching the 
logical construct within the other complete file.  This way the physical 
boundaries of files in the lessons are immaterial (thus, they cannot 
interfere).

I do *not* use external parsed entities for an information sharing scheme 
... I use any one external parsed entity as a convenience in only one 
instance and don't "use them with other chunks".

It is this convenience and functionality that I don't want to disappear.

Yes, I can understand those who don't want to give users enough rope to 
hang themselves, but I don't think we can legislate all barriers to 
abuse.  Certainly it behooves us who work with this technology to preach 
that external parsed entities are unacceptable for fragment reuse (thank 
you, Eliot, for doing so publicly), but if people won't listen, is that the 
design's fault?  Does the feature *have* to disappear?

............... Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 15:57:04 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:16:48 2004
Subject: Offtopic : Eclectic weblog
In-Reply-To: <000f01bf2c4c$12a800c0$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <001e01bf2c5d$3eb39380$ab20268a@pc-lrd.bath.ac.uk>

> I last updated this morning, and not several weeks ago as 
> it claims. I hope to iron the glitches out soon.

Done. Dave Winer has been kind enough to set up a Manila 
based weblog for me at http://weblogs.userland.com/eclectic/.

The site has been transferred, and I'll be making any 
further updates there.

Any feedback most welcome.

Cheers,

L.

==================================================================
    "Never Do With More, What Can Be Achieved With Less"
				---William of Occam
==================================================================
Leigh Dodds                             Eml:  ldodds@ingenta.com
ingenta ltd                             Tel:  +44 1225 826619
BUCS Building, University of Bath       Fax:  +44 1225 826283

HomePage :				 	http://www.bath.ac.uk/~ccslrd/
WebLog   :			     http://weblogs.userland.com/eclectic/
==================================================================

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 16:01:31 1999
From: philipnye at freenet.co.uk (Philip Nye)
Date: Mon Jun  7 17:16:48 2004
Subject: Lightweight XML
References: <9D7F61B87714D31194530090276212440C988F@outback.internal.outbackinc.com>
Message-ID: <382AE82D.17E282B9@freenet.co.uk>



Jay Chalfant wrote:
> 
> In working on thin clients over thin pipes, I've had two notions regarding
> XML:
> 
> 1) Compressed XML: Not generic text compression, but DTD-specific
> compression. It seems that if I have a document that conforms to a given DTD
> that I could apply a generic transform (input DTD and document) that would
> produce a minimal representation of the document. Readers of the document
> would need to know the DTD and the generic transform used. Anybody know of
> such a transform or work in this area?
> 
> 2) Lightweight parser: If I am building a system that uses a single DTD,
> there should exist the potential to produce a parser that is much lighter
> that a standard (non-validating) parser. Does anybody know of a tool that
> would accept DTD as input and produce source code for the "single-DTD"
> parser?
> 
> All comments welcome. Thanks.

I think the lightweight parser is an excellent idea - let me know when
you have done it! It would be very welcome in a project I am developing
where code size is potentially very important.

Philip

-- 
Philip Nye
Engineering Arts
72 Herberton Road  ~  Bournemouth  BH6 5HZ  ~  UK
tel +44 (0)1202 418236  ~  fax +44 (0)1202 418676
mailto:philipnye@freenet.co.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Anthony_Davis at spree.com  Thu Nov 11 16:04:36 1999
From: Anthony_Davis at spree.com (Anthony_Davis@spree.com)
Date: Mon Jun  7 17:16:48 2004
Subject: unsubscribe
Message-ID: <015da4203160bb9PORTAL@portal.spree.com>

unsubscribe


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



From kragen at pobox.com  Thu Nov 11 16:12:47 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:16:48 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <Pine.GSO.4.10.9911111109550.24428-100000@kirk.dnaco.net>

G. Ken Holman writes:
> My XSLT/XPath book is written in XML.  For downstream processing of the PDF 
> it needs to be one large contiguous instance.
> 
> For editing, I have every individual lesson (each between one and 10 frames 
> in length) in individual external parsed entities.  The entirety is over 
> 300 printed pages ... I don't want to pull all of that into my editor to 
> work on a single lesson.

Hmm.  So the reason external parsed entities are useful to you is that
you use an editor that can't handle editing a 5-megabyte file
painlessly?  If you were using Emacs, which easily handles editing
multi-hundred-megabyte files, would your need for external parsed
entities go away?

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gkholman at CraneSoftwrights.com  Thu Nov 11 16:37:06 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:16:48 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <Pine.GSO.4.10.9911111109550.24428-100000@kirk.dnaco.net>
Message-ID: <4.2.0.58.19991111113026.00ae3c50@pop1.attglobal.net>

At 99/11/11 11:12 -0500, Kragen Sitaker wrote:
>G. Ken Holman writes:
> > My XSLT/XPath book is written in XML.  For downstream processing of the 
> PDF
> > it needs to be one large contiguous instance.
> >
> > For editing, I have every individual lesson (each between one and 10 
> frames
> > in length) in individual external parsed entities.  The entirety is over
> > 300 printed pages ... I don't want to pull all of that into my editor to
> > work on a single lesson.
>
>Hmm.  So the reason external parsed entities are useful to you is that
>you use an editor that can't handle editing a 5-megabyte file
>painlessly?

No, I work better with smaller chunks of data and choose to work this way.

>If you were using Emacs, which easily handles editing
>multi-hundred-megabyte files, would your need for external parsed
>entities go away?

No.  And, Emacs doesn't give me the features I want when I write.

But I think that is beside the point.  Should tools be limiting the way I 
work?  Hopefully not.  I want to work with small chunks and external parsed 
entities help me do that.

.............. Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Thu Nov 11 16:42:28 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:48 2004
Subject: Feeler for SML (Simple Markup Language)
References: <001b01bf2c59$1be27280$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <00b201bf2c63$4a807420$46d18dce@PTGRESTON>


----- Original Message -----
From: Leigh Dodds <ldodds@ingenta.com>
To: xml-dev <xml-dev@ic.ac.uk>
Sent: Thursday, November 11, 1999 10:26 AM
Subject: RE: Feeler for SML (Simple Markup Language)



>
> Well isn't your contract between your and Dons processors going to be
> the 'protocol' for your application. Can't that protocol just say
> "We're using XML, but without any attributes, and...". You've still got
> to define the message formats so define them without recourse
> to PIs, entities, attributes, etc, etc

That's a good point ... I guess it's a bit hard to make a case for something
like SPL on the typical Internet platform with a big server and a powerful
browser and a built-in standard XML processor.  And perhaps this can be
addressed at the level of protocols and schemas, not the meta language
itself.  Nevertheless, it still seems useful to explore the idea of defining
a class of XML-ish schemas, protocols, and the tools that can process them
by defining a subset of XML itself that is optimized for situations where
entities, notations, validation, etc. are inappropriate.

I for one am most interested in its applicability to light client, low
bandwidth environments such as phones or PDAs ... and extremely high
transaction volume messaging or database applications.  Someone on this list
asked yesterday for ideas about using XML in an application that required
something like 100MB of data to be analyzed and stored in a second. That is
probably WAY beyond the capabilities of any current XML system I know of,
but is the KIND of scalability that the largest enterprise applications will
require soon, if they don't today. (Witness the performance and reliability
problems that various wildly successful e-commerce sites are having for an
example of the importance of architecting scalability in at the beginning of
a project ...).

XML as we know it has numerous features -- see Don's list -- that seem much
more applicable to traditional SGML-ish document processing applications
than enterprise-scale (or low footprint/bandwidth) data processing
applications.  It appears to me that XML and its current tools have
*adequate* responses here, e.g. your example of dynamically loading
entity-resolving code when I get a message that some *$#@^% put an external
entity reference in ;~)   On the other hand, I'm not at all convinced that
XML now has the OPTIMAL response here. It would appear to me that there is
considerable potential -- and I would want to see performance data
supporting this notion before investing heaviliy in it -- for improving the
scalability of data XML processing tools by using a subset of the spec that
doesn't have the SGML text processing legacy in it.


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



From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Nov 11 16:47:51 1999
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon Jun  7 17:16:48 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <4.2.0.58.19991111113026.00ae3c50@pop1.attglobal.net>
References: <Pine.GSO.4.10.9911111109550.24428-100000@kirk.dnaco.net>
	<4.2.0.58.19991111113026.00ae3c50@pop1.attglobal.net>
Message-ID: <14378.62213.319538.484083@spqr.oucs.ox.ac.uk>

G. Ken Holman writes:

 > No, I work better with smaller chunks of data and choose to work this way.

hear hear. I have written/produced a good few books, and the idea of
working on the whole book at a time is ludicrous, for several reasons.
Of course you want a master file which refers to fragments. If for no
other reason than to juggle the order trivially.

Sebastian Rahtz


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



From vlashua at RSGsystems.com  Thu Nov 11 16:53:57 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CB9@MAILPROD>

That's what a dtd is for!
It's the contract!
Vane

-----Original Message-----
From: Michael Champion [mailto:Mike.Champion@softwareag-usa.com]
Sent: Thursday, November 11, 1999 9:57 AM
To: xml-dev
Subject: Re: Feeler for SML (Simple Markup Language)



----- Original Message -----
From: Leigh Dodds <ldodds@ingenta.com>
To: xml-dev <xml-dev@ic.ac.uk>
Sent: Thursday, November 11, 1999 9:19 AM
Subject: RE: Feeler for SML (Simple Markup Language)



> What would we gain from SML that we couldn't gain from only
> producing (and therefore processing) XML documents but
> without any of the 'additional' features?

A "standard", or really a sortof an informal contract, saying I won't send
you messages or documents with any attributes, PIs, entities, etc.
This lets you optimize your code to be blissfully ignorant of them.  But
without
a "contract" saying what we won't send each other, there are many potentials
for interoperability failures.  I might send Don a document with attributes
(which
I happen to like) but his processor chokes on. It would be better to form
a wide consensus on EXACTLY what subset of XML the "SML community" would
understand.

>
> If I don't want to have attributes, or PIs, or use entities,
> etc. then I don't *have* to. Granted the SAX/DOM APIs
> still provide support for these constructs, but
> I can still ignore them surely? (and I still retain
> the option to use them at a later date).

Right.  But your true-XML parser, DOM/SAX APIs, transformation
engines, etc. will be bloated with all sorts of code that will never be
executed.  If I'm writing applications for cellphones, that matters!





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



From harvey at eccnet.eccnet.com  Thu Nov 11 17:27:45 1999
From: harvey at eccnet.eccnet.com (Betty L. Harvey)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <Pine.LNX.4.04.9911111155440.27451-100000@eccnet.eccnet.com>


Don:

	I think it is an interesting idea but not good for the XML
community as a whole.  XML is already very fragmented and confusing to the
'newbie'.  If you ask 10 people who have heard about XML but are not
ingrained in the XML specification - "What is XML?", I guarantee you will
get at least 8 different answers. By adding another subset and 'ML' into
the mix we will add considerable confusion. Individuals can now scale XML
down for their own purposes.  You can do the same scaling with any other
computer technology, JAVA, Perl, etc.  Use what you need.

	I have reading the threads from the last few days with interest
though. It took me a few moments this morning to realize Rick's message
this morning on XML 2.0(alpha) was a joke. In all fairness it was before
my morning coffee but I did almost have a slight coronary |-).

	Just a couple of comments on recent posts on external parsed
entities and Unique ID's:

Eliot - I never knew you thought parsed entities were 'evil'.  I knew
        you didn't particularly like them but the 'Darth Vader of XML'
	|-).  I also agree with you that the 'valueref' of HyTime would
        be extremely useful - but XLink should do the job.

Like, Ken, I have found external entities to be really useful in creating
reusable components.  However, IDs and parsed external entities have a
tendency to be problematic - even in a controlled environment.  They will
be even more problematic when we really start creating 'global' documents,
i.e., virtual catalogs.

Betty

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey                         | Phone: 301-540-8251 FAX: 4268
Electronic Commerce Connection, Inc. | 
13017 Wisteria Drive, P.O. Box 333   | 
Germantown, Md.  20874               |
harvey@eccnet.com                    | Washington,DC SGML/XML Users Grp
URL:  http://www.eccnet.com          | http://www.eccnet.com/sgmlug/
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/  



On Thu, 11 Nov 1999, Don Park wrote:

> Everyone,
> 
> I have been thinking that there are applications out there that
> can benefit from using XML yet donot need all of its features.
> The Canonical XML spec goes quite a distance in cutting away
> some of the features, for different purpose, but I still feel
> that more can be cut away.  Rick Jelliffe's rather funny
> message along with some WebDAV papers I read over the weekend
> got my mind buzzing enough for me to share this idea with the
> rest of XML-DEV.
> 
> What I have in mind is a subset of XML, I'll call it Simple
> (or Stupid) Markup Language (SML) for now, that simplifies XML
> down to the bare essentials.  Ideally, it should also be a
> subset of Canonical XML.  Here are some ideas:
> 
> o No Attributes (ouch!)
> o No PI, Comments, Notations, or CDATA sections
> o No document type declaration
> o UTF-8 encoding only
> o No non-character entity references
> o No predefined character entities (I am iffy on this one)
> 
> What do you guys think?  Please do not get caught up with
> the list I presented above because they are just ideas and
> subject to change later depending on your capacity to scream
> convincingly.  The key point to consider is whether there is
> a broad enough need for such a subset of XML.
> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 17:33:20 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: "Don Park"'s message of "Thu, 11 Nov 1999 05:48:16 -0800"
References: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <m3bt91hr4f.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> What do you guys think?  Please do not get caught up with the list I
> presented above because they are just ideas and subject to change
> later depending on your capacity to scream convincingly.  The key
> point to consider is whether there is a broad enough need for such a
> subset of XML.

It's too late -- since XML has already succeeded in gaining wide
implementation as it is, it would be like buying insurance for the
previous year.  

XML has been implemented so widely, and there are so many free and
commercial parsers, libraries, and toolkits available that there would
be no significant advantage (and great dangers) in creating a separate
dialect at this point.

Even if the separate dialect is a pure subset, it will still split the
XML market for no good reason: applications that support only the
subset will reject well-formed XML documents that happen to fall
outside the subset.

That said, it's certainly useful to define APIs that hide some of that
stuff -- applications should not have to worry about unparsed
entities, notations, etc. unless they want to.  SAX was one attempt to
do so.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 17:44:34 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: Vane Lashua's message of "Thu, 11 Nov 1999 11:51:05 -0500"
References: <A51F7543E295D2118D6600A024CDB2F71B9CB9@MAILPROD>
Message-ID: <m366z8j55g.fsf@localhost.localdomain>

Vane Lashua <vlashua@RSGsystems.com> writes:

> That's what a dtd is for!
> It's the contract!

A DTD is a contract for structure, not for features.  Battle-scarred
SGML veterans will remember the SGML declaration, which was the
contract for what features need to be supported by both ends ("I
promise not to use names longer than 8 characters", etc.).  The SGML
declaration was first against the wall when the XML revolution came.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 17:45:05 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: "Hunter, David"'s message of "Thu, 11 Nov 1999 09:53:59 -0500"
References: <805C62F55FFAD1118D0800805FBB428D02BC00A1@cc20exch2.mobility.com>
Message-ID: <14379.74.436084.458156@localhost.localdomain>

"Hunter, David" <dhunter@Mobility.com> writes:

> Perhaps from the point of view of a parser writer, this might be a
> good thing.  If you knew you were never going to need these
> constructs, you could build a smaller, faster parser.

Not much smaller, I'm afraid -- for an event-based parser, support for 
PIs and attributes adds almost no overhead (I remember experimenting
with putting them in and leaving them out when I was writing
AElfred).

AElfred, by the way, was under 15K in a compressed JAR file when I was
maintaining it, though it wasn't strictly conformant (it didn't report
all required errors) -- I still believe that someone could write a
Java-based XML parser in under 10K (compressed) if they had the time
and inclination and made more use of the standard Java libraries.

> From the point of view of applications that use XML, however, SML
> would not provide much gain, except perhaps the slight speed
> advantage of using one of these stripped down, souped up parsers; as
> Leigh Dodds pointed out, you could just use XML without the features
> you don't need.

Agreed.

If we were still designing XML, I would be in favour of at least a
good part of Don's list, but now that the deed is done and we've
obviously won (the only debates now are what XML-based languages to
use), we should learn to live with the XML syntax that we have and
concentrate on the higher-level stuff.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From BBerck at ESPS.com  Thu Nov 11 17:44:49 1999
From: BBerck at ESPS.com (Ben Berck)
Date: Mon Jun  7 17:16:49 2004
Subject: XSL patterns give me a node--how can I find it's position?
Message-ID: <4139ED560536D3118F100008C7F36E451A8D38@HQMAIL>

I am using the (IE5) XML DOM to search for a particular node.

I use a pattern like this: 
books/book[@bnum = 13241]

It correctly finds a match.  Now my question is, how do I determine the
position of the found book in "books"?  bnum is not in sequential, nor is it
in order.  I need to know which book it is within the books.childNodes
NodeList. 

Do I have to step through every element of books.childNodes and match it
myself?

Thanks in advance,
Ben Berck
ESPS, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991111/4e8d7081/attachment.htm
From ken at bitsko.slc.ut.us  Thu Nov 11 17:57:09 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: "Don Park"'s message of "Thu, 11 Nov 1999 05:48:16 -0800"
References: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <m3n1sk29pp.fsf@biff.bitsko.slc.ut.us>

"Don Park" <donpark@docuverse.com> writes:

> I have been thinking that there are applications out there that can
> benefit from using XML yet donot need all of its features.  The
> Canonical XML spec goes quite a distance in cutting away some of the
> features, for different purpose, but I still feel that more can be
> cut away.  Rick Jelliffe's rather funny message along with some
> WebDAV papers I read over the weekend got my mind buzzing enough for
> me to share this idea with the rest of XML-DEV.

There have been many threads on "XML could have/should have been much
simpler if they had just done XYZ" often referring to Scheme or TeX
syntax, for example.

I too have had one of those brainfarts because I like to hand edit XML
and it's way too bulky in most cases.  I've been playing with an "XML
shorthand" that follows the Scheme camp's proposals (I originally
started out with a TeX style ;-).  One of the key requirements,
though, is the need to be interoperable with XML 1.0.  Here's what I
came up with.  The basic syntax only sees what XML people would call
"elements" and "character data", all other XML structures are actually
built from XML-SH "elements".  XML-SH "element names" may contain XML
special characters.  First an example with minimal XML markup:

  {p I've been playing with an {quote XML shorthand} that follows the
  {language Scheme} camp's proposals {note{=type parenthetical} I
  originally started out with a {language TeX} style {wink}}.  One of
  the key requirements, though, is the need to be interoperable with
  {standard{=version 1.0} XML}.}

With more XML markup:

  {?xml{=version 1.0}}
  {!DOCTYPE{=PUBLIC -//blah/}{=SYSTEM foo.dtd}
   {!ELEMENT foo (#PCDATA|subfoo)*}
  }
  {foo this is a foo, {subfoo this is subfoo.}
   This is {subfoo{=bar with an attribute}}.}


And a very rough draft of the basic syntax:

  Document ::= (Element | S)*

  Char ::= #x9 | #xA | #xD | [#x20-#xD7FF]
          | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
        /* as defined in XML 1.0 */

  S ::= (#x20 | #x9 | #xD | #xA)+
        /* as defined in XML 1.0 */

  Element ::= StartDelim (Char - S)*
              (S | StartDelim | EndDelim) Char* EndDelim
        /* This is meant to state that an element starts with a
           StartDelim, followed by zero or more non-white space
           characters, and may contain mixed content (starting with
           another StartDelim or S), and ending with EndDelim.  Empty
           elements are represented using {TAG}, no space after tag
           content is represented using {TAG{}content} */

StartDelim and EndDelim are charset-dependent.  For ASCII I'd use `{'
and `}' as in the examples above.  In Unicode I'd really like to see
two characters dedicated to this purpose so markup can never conflict
with character data.

Interoperability with XML 1.0 is implemented using a transform and
well-formedness constraints in XML-SH.  "Well formed" in XML-SH would
mean "well formed when converted to XML 1.0".

The transform is fairly guessable from the above.  The XML-SH parser
reads everything as elements and character data, the transformer
recognizes elements that are actually XML structures and converts them
appropriately.  An XML-SH compliant parser should not need to generate
XML events directly, depending on a transform filter to do that
instead.  A minimal filter should be provided to restrict passing
non-well-formed element names in startElement()/endElement() events.
This may (should) also involve gathering attribute-elements into
startElement() attributes.  More examples of transformable XML-SH:

 {?TARGET DATA}                          -- processing instruction
 {?TARGET {=NAME VALUE}}                 -- a PI using attr form
 {!DOCTYPE {=PUBLIC FPI} {=SYSTEM URI}   -- start of DOCTYPE
   {!ELEMENT NAME CONTENTSPEC}           -- element declaration
 }
 {!-- COMMENT}                           -- comment
 {&ENTITYREF}                            -- entity reference
 {&#123}                                 -- character reference
 {&#xabcd}                               -- hex character reference
 {NAME ...}                              -- an element with content
 {NAME{=ATTR VALUE} ...}                 -- an element with attributes
 {NAME{}...}                             -- element w/o extra whitespace
 {NAME followed by many lines of text
   {/NAME}}                              -- a no-op used as a comment

Some messages in this thread refer to "contracts".  Several of these
contracts could be based on limiting what features the XML transformer
will allow.  For example, there is no support in the XML-SH parser for
external entities, that's left to the transformer.

-- 
  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gkholman at CraneSoftwrights.com  Thu Nov 11 18:06:52 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:16:49 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <Pine.LNX.4.04.9911111155440.27451-100000@eccnet.eccnet.com
 >
References: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <4.2.0.58.19991111125925.0096ef00@pop1.attglobal.net>

At 99/11/11 12:30 -0500, Betty L. Harvey wrote:
>         Just a couple of comments on recent posts on external parsed
>entities and Unique ID's:
>
>Eliot - I never knew you thought parsed entities were 'evil'.  I knew
>         you didn't particularly like them but the 'Darth Vader of XML'
>         |-).  I also agree with you that the 'valueref' of HyTime would
>         be extremely useful - but XLink should do the job.
>
>Like, Ken, I have found external entities to be really useful in creating
>reusable components.

Actually, I've been trying to explain that I don't use them in creating 
*reusable* components, but merely to fragment large works into manageable 
pieces (manageable for me, not my tools).

Indeed, problems arise when trying to use them as reusable components 
because they aren't designed richly enough to support that well.

When I've needed reusability I've done so at a semantic level, not a 
syntactic level.  That was the reference I made to needing to take one 
lesson from another presentation to include in a given presentation ... I 
refer to the lesson by ID and the other presentation by URI and my 
*production* system (built with XSLT applying concepts of applicability and 
effectivity) brings the two together ... not my authoring system or XML 
processor.

As a result of personal experience trying to do so, I now don't counsel 
external parsed entities be used as reusable fragments.

I hope this detail helps.

.......... Ken


--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 18:17:43 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:49 2004
Subject: Why do we write standards?
References: <SIMEON.9911101038.B@PC7155.emcins.com>
Message-ID: <382B083E.1DF01151@pacbell.net>

"Michael S. Brothers" wrote:
> 
> This thread is fascinating. I liken much of what I have heard to the
> efforts to standardize HDTV, and if you look at that, it's hard to call
> standardization anything else but good for consumers. 

HDTV is actually an interesting example.  Look at the debates over
just what HDTV should be ... square pixels (making life easier for
companies working with digital content already) vs rectangular ones
(making existing analog content provider companies happier), pure
digital (new vendors) vs incremental evolution (installed base), etc.

All the issues there have a strong "this answer is better for me"
vendor tie.  Yet ... exactly which consumers were beating down doors
to get that?  Not many, and the HDTV standards took years to stabilize.
Vendor push was essential; and of course, customer indifference to
most early versions.  There were governmental issues too.

Just because consumers _eventually_ get a benefit doesn't preclude
corporations using standards process to achieve strategic advantage.
That's a very well known aspect of standards strategies; if you play
effectively, the consumer dollars go to _your_ company, not to your
competitors.  The game theoretic result is also visible:  companies
work to water down anything that'd give too much focus.  "Committee
design" specs are a familiar outcome of such a process.

 
> Standards are not Socialist, nor are they in the best interest of a
> consortia, rather are the key to true consumer freedom. 

I'm not sure where that comes from, but if you are claiming that
corporate interests don't have a strong (and sometimes compelling)
degree of leverage over the standards which get developed, I strongly
suggest that you look more closely at even just the last ten years
of technology development.  "Joe Sixpack" doesn't propose standards,
or even directly fund their evolution.

That fits into the "top down"/"bottom up" ("how") dimension as affecting
motivations ("why").  As the man said, "follow the money ...".

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lauren at sqwest.bc.ca  Thu Nov 11 18:26:26 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:16:49 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <382A8FE3.51D9788E@pacbell.net>
Message-ID: <199911111823.KAA00953@mail.sqwest.bc.ca>

On 11 Nov 99, at 1:44, David Brownell wrote:

> Perhaps the general issue is that whenever DOM starts to offer
> APIs for populating a DOM Document, there need to be options
> about what features should be exposed.  For my usage, things
> like EntityReference and CDATASection (vs normal Text) would
> hardly ever be used.
> 
> Or perhaps there should be variants of Element.normalize() that
> give you other options for getting rid of extra tree nodes.
> "No adjacent text nodes" is covered.  How about flags for cases
> like "don't use EntityReference", "don't use CDATASection",
> and "don't use Comment"?

That seems like an idea worth tossing around. We'll be starting to 
figure out requirements for Level 3 shortly - how about you write up 
this proposal in a little more detail? We have in the past discussed 
"normalizing" CDATA sections, but didn't find enough compelling 
use cases, and it only takes a couple of steps for the user to do it 
themselves, so it wasn't added. If you can add some compelling 
use cases, that would help the case for adding yet another set of 
methods to the DOM :-)

Please send any proposal to www-dom@w3.org so it's archived in 
the right place, and I'll make sure the DOM WG discusses it when 
we get that far.

thanks,
Lauren

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



From rja at arpsolutions.demon.co.uk  Thu Nov 11 18:31:24 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:16:50 2004
Subject: XSL patterns give me a node--how can I find it's position?
References: <4139ED560536D3118F100008C7F36E451A8D38@HQMAIL>
Message-ID: <005001bf2c72$8c02f080$c5010180@p197>

Forgeting the nodes collections (because it is an overhead getting that
anyway), once you've got the node your interested
it, simply do something like this:

' Grab the node via an XSL pattern

dim iCount as integer
set node = dom.selectNodes( "whatever XML pattern" )
iCount = 0

' While this node is not the first chlid node

while not (node.prevSibling is nothing) then

    ' Add one to count and move back

    iCount = iCount + 1
    set node = node.prevSibling

Wend

Basically you just count until there is nobody to your left, then the count
should give you the index you need.

HTH,

Rich.

DEV-XML - THE *new* Windows/MSXML Developer Maiing List - To join send a
blank
email to dev-xml-subscribe@onelist.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lauren at sqwest.bc.ca  Thu Nov 11 18:35:00 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:16:50 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <Pine.GSO.4.10.9911111109550.24428-100000@kirk.dnaco.net>
Message-ID: <199911111831.KAA25314@mail.sqwest.bc.ca>

On 11 Nov 99, at 11:12, Kragen Sitaker wrote:

> Hmm.  So the reason external parsed entities are useful to you is that
> you use an editor that can't handle editing a 5-megabyte file
> painlessly?  If you were using Emacs, which easily handles editing
> multi-hundred-megabyte files, would your need for external parsed
> entities go away?

It isn't only editing. The W3C DOM spec is authored in XML and 
then transformed into the language bindings, HTML, PDF, etc. 
There are several editors who work on the specification, often 
simultaneously (e.g., when we 're trying to get out the next public 
draft). We upload onto the W3C server when we've finished editing 
whichever chunk of the spec we're working on. The chaos of 
locking a complete spec until someone has finished editing their bit 
would be disruptive (OK, we could use a complete XML repository 
solution, but we don't, we use a standard CVS repository). And the 
time it would take on a slow modem link to upload the complete 
spec is also large. It's much easier to work in small chunks: 
quicker to upload and download, easier to manage simultaneous 
work, etc. External entities are just what we need and use.


Lauren

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



From Andy.Bradbury at syntegra.bt.co.uk  Thu Nov 11 18:50:01 1999
From: Andy.Bradbury at syntegra.bt.co.uk (Andy.Bradbury@syntegra.bt.co.uk)
Date: Mon Jun  7 17:16:50 2004
Subject: external unparsed entities in a XML document
Message-ID: <65AF45D5E535D2118AFB0008C7FA23180C3E41@FL-EXCHANGE-03>

Murali

Please excuse my previous mail, I obviously completely misunderstood your
question.
The trouble with such an open list is that you never know whether someone is
a newbie or not until they've posted a message or two.  I realise now that
you definitely do not belong in this category.

Regards

Andy B.


-----Original Message-----
From: Murali [mailto:murali@ntexchtx.hq.ileaf.com]
Sent: 11 November 1999 14:59
To: 'philipnye@freenet.co.uk'; Murali
Cc: 'xml-dev@ic.ac.uk'
Subject: RE: external unparsed entities in a XML document


Hi Philip

I think i did not put properly my question. 
What i want to know is when i am parsing the XML document ( either using DOM
api or 
SAX api ) is it possible to find out what subset of external entities
defined in the DTD
are used in the XML document? 
e.g., In the SAX api, there is a listener called "Entityresolver" ( which
will be called 
when parser encounters either parsed or unparsed external entities). But it
looks like this
method is not getting called for the "external unparsed" entites.

thanks for you help.
Murali
-----Original Message-----
From: Philip Nye [mailto:philipnye@freenet.co.uk]
Sent: Thursday, November 11, 1999 8:22 AM
To: Murali
Subject: Re: external unparsed entities in a XML document


> Is it possible to find out the what are the "external unparsed entities"
in
> an XML document ?

Yes it is but it is quite hard to find all the pieces in the XML 1.0
Spec.

External unparsed entities are values which attributes may take. Look at
sections 4, 4.2.2 and 3.3 and production [56] for a start.

e.g. Usage looks something like this.

In the DTD

<!NOTATION someNotation PUBLIC "notationIdentifier" >
<!ENTITY EUEinstance SYSTEM "whereToGetItFrom" NDATA someNotation >
<!ELEMENT anElement EMPTY >
<!ATTLIST anElement entityAttribute ENTITY>

then in the document

<anElement entityAttribute="EUEinstance" />


Philip Nye
-- 
Philip Nye
Engineering Arts
72 Herberton Road  ~  Bournemouth  BH6 5HZ  ~  UK
tel +44 (0)1202 418236  ~  fax +44 (0)1202 418676
mailto:philipnye@freenet.co.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 11 19:51:22 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:16:50 2004
Subject: Why do we write standards?
References: <000801bf2bf3$24d5c560$099918d1@docuverse1>
Message-ID: <382B1E08.D73EBF5B@prescod.net>

Don Park wrote:
> 
> Paul Prescod wrote:
> >> HTML 4.0 specification
> >> XHTML 1.0
> >
> >These specifications *do not apply* to XHTML mixed with other
> >specifications. They don't say what it means to have a TITLE
> >in a FOOBAR in a table. They just don't answer the relevant question!
> 
> On the contrary, I can not see how anyone who reads the TITLE element
> section of the HTML 4.0 spec can decide to use it inside anything
> other than the HEAD element.  If the designer wants to reuse the
> tag name 'title' then he should not be using the HTML namespace for
> the TITLE tag.

The title is metadata for a document. An HTML-ish variant might allow
FOOBARs to be like HTML documents embedded in other documents. Then a
FOOBAR needs a title just as other HTML documents need titles.

> >> XHTML 1.1 - Module-based XHTML
> >> Modularization of XHTML
> >> Building XHTML Modules
> >
> >Great. When these specifications are done, we can standardize a
> >namespace.
> 
> While these specs are not done yet, they are already a great
> resource for those trying to design composite documents.  Many
> knowledgable folks have spent a great deal of effort writing these
> specs and I totally disagree with the position that these specs
> are worth nothing until it reaches Recommendation status.

You are addressing a different issue. You are talking about using these
specifications and their associated namespace experimentally. Previously
you and David were talking about creating a namespace with no normative
reference to these specifications. Then people would just use their
"common sense" instead of requiring adherance to the specifications.
That's a very different thing.

It's the difference between encouraging experimentation with XML before
XML is done and inventing the XML declaration before inventing XML.
"Just put this on top of an SGML document and use your common sense.
Once enough of these XML-labelled documents are out there, we'll see
what people are doing and standardize it."

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Chaos is the Engine" - 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 20:34:44 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:50 2004
Subject: Why do we write standards?
In-Reply-To: <3829C0C9.EBAF6908@prescod.net> (message from Paul Prescod on
	Wed, 10 Nov 1999 13:00:25 -0600)
References: <3829C0C9.EBAF6908@prescod.net>
Message-ID: <199911111947.NAA01380@bruno.techno.com>

[Paul Prescod:]

> "Product XYZ supports the XHTML namespace. We use it in completely
> different ways than anyone else and our software crashes with many
> documents that other people create using XHTML, but we are XHTML
> namespace compatible!" What's the damn point?

I may be wrong, but the only point I can see is the fact that vendors
can make the claim, "We are XHTML namespace compatible", without
having to worry about such a claim actually meaning anything.  Forgive
my cynicism, but isn't this namespace hoohah really all about fig
leaves and marketing and causing customers to have rosy expectations?
So far, I don't see much relevance to information interoperability, or
vendor neutrality.  With respect to the importance of vendor
neutrality, 

[Michael Brothers wrote:]

> ... Broadcasters beam one type of signal, sets receive [the same]
> type of signal. The plus side is that once the standard was
> established, all industry participants had access, and any company
> could start producing broadcast hardware or HDTV sets. Thus,
> consumers will reap the benefits of competition between Sony,
> Philips/Magnavox, Toshiba, etc by having a choice of features and
> lowering prices as the technology matures....

If the precise nature of a conforming signal is not rigorously
defined, the benefits of level-playing-field competition cannot be
realized.  Instead, you get Microsoft (just for an example) having its
own flavor of XHTML, and nobody being able to do anything about it, or
to point the finger of blame.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From vlashua at RSGsystems.com  Thu Nov 11 20:52:00 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:50 2004
Subject: XML Support for Software Agents
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CBE@MAILPROD>

If you can say 'To:. . .', you can say "<mymailagent:to>. .
.</mymailagent:to>".".

-----Original Message-----
From: vikas jaitly [mailto:vikas@adithya.ncb.ernet.in]
Sent: Thursday, November 11, 1999 5:09 AM
To: xml-dev@ic.ac.uk
Subject: XML Support for Software Agents


Hi ,
 
        Can XML be used as an inter-agent communication language. Is there
any support site for this type of information ?
 
Thanx,
Vikas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991111/c75ac071/attachment.htm
From jes at kuantech.com  Thu Nov 11 21:05:08 1999
From: jes at kuantech.com (Jeffrey E. Sussna)
Date: Mon Jun  7 17:16:50 2004
Subject: Worried about Namespaces and Schemas
Message-ID: <000f01bf2c87$849270e0$0f36a8c0@quokka.com>

I have been too busy with so-called real work lately to pay much attention
to theretical XML issues. I have, however, been worried by the ongoing
conversation about namespaces and schemas, particularly the implications of
lack of strong connection between them. The only thing I've formally
implemented using XML so far is RDF. RDF does specify a strong connection
between a namespace and a schema. So I am left with the nagging fear that
something is fundamentally and badly broken in XML land, and that it will
bite me hard on the ass. Does anycare to translate the intelligent but not
transparent namespace-schema thread into something I can evaluate without
heavy analysis. I'm usually capable of that level of analysis, but as I said
I'm too busy these days.

TIA,
Jeff Sussna


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



From vlashua at RSGsystems.com  Thu Nov 11 21:07:15 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:50 2004
Subject: DOM -> SQL -> DOM: Serialization...
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CBF@MAILPROD>

quality, time, scope, cost: for this one use Perl, first.
Vane

-----Original Message-----
From: Kevin A. Burton [mailto:burton@relativity.yi.org]
Sent: Thursday, November 11, 1999 4:56 AM
To: xml-dev@ic.ac.uk; cocoon@list.working-dogs.com
Subject: DOM -> SQL -> DOM: Serialization...


I need to take a ton of XML documents... about say 100M and run analysis
on them in realtime.  (less than 1 second)

I am planning on using a parser to return a DOM, then take that DOM and
Serialize it to SQL with maybe ENTITY|ATTRIBUTE|CDATA tables, etc.  And
then write an interface (maybe XMLQL) to get the data.

Has anyone seen an Open Source project to do this?

Kevin

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



From l-arcini at uniandes.edu.co  Thu Nov 11 21:46:06 1999
From: l-arcini at uniandes.edu.co (Fabio Arciniegas A.)
Date: Mon Jun  7 17:16:50 2004
Subject: DOM -> SQL -> DOM: Serialization...
In-Reply-To: <19991111051014.78338.qmail@hotmail.com>
Message-ID: <000e01bf2c8d$92d4e560$0100000a@phoebe>

Kevin, I agree 100% with Prakash about the time restriction. During the
development of Samxa and Munin(two of my xml projects) i was faced with a
similar problem and definetly the cost of  deserializing/serializing DOM
docs was excesive to my needs (which were lighter than yours!)

The kind of solution you need depends largely on what kind of analysis you
need to run on the docs... for me, things were solved watching for regular
expresions on the startElement and characterData callbacks of a sax
parser... then again, i somehow suspect you need much more than that.
anyway,if you want, email me to tell me more about your kind of analysis and
maybe i can help with a bit of samxa code.

Fabio



- -----Original Message-----
- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
- Prakash Mandgi
- Sent: Jueves, 11 de Noviembre de 1999 12:17 a.m.
- To: Kevin A. Burton; xml-dev@ic.ac.uk; cocoon@list.working-dogs.com
- Subject: Re: DOM -> SQL -> DOM: Serialization...
-
-
- Hi Kevin
-
- with sql server / oracle i doubt you can retrieve that data so fast
- especially over
- the network let alone parse it.
- You may want to consider using Object databases
- 1) Persist DOM documents as is in an object database and then run XQL /
- XPath etc
- 2) Use entity java beans to store the DOM document in memory
-
- You can pretty much forget about serializing / deserializing DOM documents
- of that size in less than a second.
-
- Prakash
-
- ----- Original Message -----
- From: Kevin A. Burton <burton@relativity.yi.org>
- To: <xml-dev@ic.ac.uk>; <cocoon@list.working-dogs.com>
- Sent: Thursday, November 11, 1999 4:56 AM
- Subject: DOM -> SQL -> DOM: Serialization...
-
-
- > I need to take a ton of XML documents... about say 100M and run analysis
- > on them in realtime.  (less than 1 second)
- >
- > I am planning on using a parser to return a DOM, then take that DOM and
- > Serialize it to SQL with maybe ENTITY|ATTRIBUTE|CDATA tables, etc.  And
- > then write an interface (maybe XMLQL) to get the data.
- >
- > Has anyone seen an Open Source project to do this?
- >
- > Kevin
- >
- > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
- > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
- CD-ROM/ISBN 981-02-3594-1
- > To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
- > unsubscribe xml-dev
- > To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
- unsubscribe xml-dev
- To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Thu Nov 11 21:59:08 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:50 2004
Subject: Feeler for SML (Simple Markup Language)
References: <000201bf2c4b$6a56b560$099918d1@docuverse1> <m3bt91hr4f.fsf@localhost.localdomain>
Message-ID: <001301bf2c8f$8f202fe0$04d88dce@PTGRESTON>


----- Original Message -----
From: David Megginson <david@megginson.com>
To: <xml-dev@ic.ac.uk>
Sent: Thursday, November 11, 1999 12:31 PM
Subject: Re: Feeler for SML (Simple Markup Language)


>
> It's too late -- since XML has already succeeded in gaining wide
> implementation as it is, it would be like buying insurance for the
> previous year.

Perhaps, but just as XML inself sprang from a concern that the SGML standard
was far too complex for Web applications, I'm seeing increased concern that
the XML standards are getting too complex, and the standards processes too
slow moving,  to really meet the needs of e-business. See, for example the
"Less is More in E-Business" articles and discussions on xml.com this week.
http://www.xml.com/pub/1999/11/edi/index.html

"The W3C is currently reviewing a complex family of draft documents from XML
technology working groups ... [with] the goal to add greater functionality
to the base XML language for document generation and processing.

While these new functions will no doubt have value in the publishing world
...
Opportunities for XML are limited by the mechanics of the syntax and the
methods and techniques they either enable or mandate. Traditional EDI
technology was hamstrung in the past by arcane syntax that only experts
could fathom. Much of the success of HTML, on the other hand, has come from
the broad accessibility of that technology. Even lay people with little
computer knowledge can create Web content. To gain and ensure broad use of
XML, general users must get results as easily and consistently as they do
with HTML."

> Even if the separate dialect is a pure subset, it will still split the
> XML market for no good reason

I guess the reason why I'm intrigued by Don Park's proposal is that it seems
to me (especially having made a career move from a text/publishing XML
vendor to an enterprise commerce XML vendor)  like there *is* a good reason
for considering whether the set of XML features needed by e-business
applications is massively smaller than the set needed by text
authoring/publishing/browsing applications.

> That said, it's certainly useful to define APIs that hide some of that
> stuff -- applications should not have to worry about unparsed
> entities, notations, etc. unless they want to

Right.  Maybe the "SML" idea would meet less resistance if it referred to
XML processing tools and APIs that quietly ignored some well-defined set of
legal XML constructs (attributes, comments, PIs, notations, entities, or
whatever) in well-formed XML documents rather than defining a subset of XML
itself in which these are illegal. I think that's well within the spirit of
both Don's posting and the "less is more" perspective in the xml.com
articles mentioned above.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 11 22:07:41 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:16:50 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <805C62F55FFAD1118D0800805FBB428D02BC00A1@cc20exch2.mobility.com>
Message-ID: <Pine.GSU.4.10.9911111401130.14268-100000@netcom9.netcom.com>

On Thu, 11 Nov 1999, Hunter, David wrote:
> Perhaps from the point of view of a parser writer, this might be a good
> thing.  If you knew you were never going to need these constructs, you could
> build a smaller, faster parser.
> 
> >From the point of view of applications that use XML, however, SML would not
> provide much gain, except perhaps the slight speed advantage of using one of
> these stripped down, souped up parsers; as Leigh Dodds pointed out, you
> could just use XML without the features you don't need.

The way I see it, the main advantage of SML would be the ability to
build a simplified API layer on top of an existing XML parser.  I'm
thinking about something like Grant McLean's XML::Simple Perl module,
which uses the existing XML::Parser module (based on Expat) to build
simple, regular data structures from arbitrary XML, and generate XML from
such data structures.  Grant originally intended it for creating flexible
application config files, but it's quite useful for parsing things like
RSS files, OSD files, etc.



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



From clark.evans at manhattanproject.com  Thu Nov 11 22:07:23 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:16:50 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <m3n1sk29pp.fsf@biff.bitsko.slc.ut.us>
Message-ID: <Pine.LNX.4.10.9911111708030.10778-100000@cantor.clarkevans.com>



On 11 Nov 1999, Ken MacLeod wrote:
>   {foo this is a foo, {subfoo this is subfoo.}
>    This is {subfoo{=bar with an attribute}}.}

{foo this is a foo, {subfoo this is subfoo.}
 This is {subfoo{@bar with an attribute}}.}

I like @ (from xpath) better than = , since
it is not really an assigment...

Clark


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



From clark.evans at manhattanproject.com  Thu Nov 11 22:16:32 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:16:50 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <4.2.0.58.19991111113026.00ae3c50@pop1.attglobal.net>
Message-ID: <Pine.LNX.4.10.9911111718060.10778-100000@cantor.clarkevans.com>



On Thu, 11 Nov 1999, G. Ken Holman wrote:
> But I think that is beside the point.  Should tools be limiting the way I 
> work?  Hopefully not.  I want to work with small chunks and external parsed 
> entities help me do that.

Ken,  

I've always been afraid of external entities.  
Do you have some examples you can share?

Thanks!

Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 11 22:21:53 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:16:50 2004
Subject: Feeler for SML (Simple Markup Language)
References: <805C62F55FFAD1118D0800805FBB428D02BC00A1@cc20exch2.mobility.com> <14379.74.436084.458156@localhost.localdomain>
Message-ID: <382B4113.87465044@infinet.com>

David Megginson wrote:

> "Hunter, David" <dhunter@Mobility.com> writes:
>
> > Perhaps from the point of view of a parser writer, this might be a
> > good thing.  If you knew you were never going to need these
> > constructs, you could build a smaller, faster parser.
>
> Not much smaller, I'm afraid -- for an event-based parser, support for
> PIs and attributes adds almost no overhead (I remember experimenting
> with putting them in and leaving them out when I was writing
> AElfred).
>
> AElfred, by the way, was under 15K in a compressed JAR file when I was
> maintaining it, though it wasn't strictly conformant (it didn't report
> all required errors) -- I still believe that someone could write a
> Java-based XML parser in under 10K (compressed) if they had the time
> and inclination and made more use of the standard Java libraries.

For Aelfred's case, it worked well for applets but would not work as well for cell phones, or
PDA's because what really counts is memory usage in these environments and regardless of
whether you use a java.util.Hashtable or your own custom version, a hashtable class and any
supporting utility classes will be loaded into memory one way or another. In this case,
writing your own smaller footprint hashtable would make more sense, so long as none of the
rest of your code made calls to libraries which loaded up a java.util.Hashtable into memory.
But since all kinds of core Java libraries use java.util.Hashtables all over the place, you
are probably better off just using java.util.Hashtable anyways.

This is one of the problems with embedded Java as I understand it because you still need to
bundle a whole bunch of unnecessary libraries with your application instead of just being
allowed to use the bare essentials that you really need.

Most of Aelfred's footprint from what I remember seemed to be character handling code and not
actual XML parsing code. If you restrict XML to be one character encoding such as UTF-8, get
rid of DTD handling (in the XML parser I have written more of my code is for parsing DTD's
than the actual parsing of an XML file) and validation, then I would not be surprised if you
could get things under 5K if you really wanted to.

I think for environments with severe memory constraints, some of Don's ideas really make
sense. Removing comments, pi's, and attributes though does not shrink your parser much as
handling each of those is only a few lines of code. Dealing with character encoding, DTD's,
and validation is where most of the bloat in an XML parser tends to go.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clark.evans at manhattanproject.com  Thu Nov 11 22:29:51 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <Pine.LNX.4.10.9911111724530.10778-100000@cantor.clarkevans.com>


I'd call it SXML...

On Thu, 11 Nov 1999, Don Park wrote:
> o No Attributes (ouch!)

Hmm.  On the plus side, this would eliminate
the famous "attribute or element" debate.

> o No PI, Comments, Notations, or CDATA sections
> o No document type declaration

Cool.

> o UTF-8 encoding only

I'm kinda ingnorant... would it still be
possible to handle oriental character sets
with UTF-8 ? 

> o No non-character entity references
> o No predefined character entities (I am iffy on this one)

Sure.  

> What do you guys think?  

Sounds like many many people are using XML
in this way *anyway* -- why not give it
a name?


Clark


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



From jamesr at steptwo.com.au  Thu Nov 11 23:07:49 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:16:51 2004
Subject: XML and SML
Message-ID: <4.2.0.58.19991112100143.00cc0a00@203.41.126.17>

An open letter to Rick Jelliffe,

Rick I was most amused by your e-mail
gently savaging all those who are trying
to ignore those aspects of XML that they
don't like.

However, I don't think you expected
it to be the catalyst for just such
a "cut down" proposal just hours later!

And for us all to waste more bandwidth
on this!

It's a strange world. :-)

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

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



From jamesr at steptwo.com.au  Thu Nov 11 23:08:46 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <001b01bf2c59$1be27280$ab20268a@pc-lrd.bath.ac.uk>
References: <005201bf2c55$10bb5ce0$46d18dce@PTGRESTON>
Message-ID: <4.2.0.58.19991112100430.00cf88e0@203.41.126.17>

At 02:26 12/11/1999 , Leigh Dodds wrote:

> > potentials> for interoperability failures.  I might send Don a document
>with
> > attributes (which I happen to like) but his processor chokes on. It would
>be
> > better to form a wide consensus on EXACTLY what subset of XML the "SML
>community"
> > would understand.

Hey, since when was there a "SML community"? :-)

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

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



From clovett at microsoft.com  Thu Nov 11 23:57:21 1999
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:16:51 2004
Subject: MSXML help
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C155E6215@RED-MSG-56>

There is a full DOM reference in
http://msdn.microsoft.com/xml/reference/xmldom/start.asp for both C++ and
Script programmers.  Documentation for IXMLDOMNode is in
http://msdn.microsoft.com/xml/reference/cvbref/IXMLDOMNode_interface.asp

You will also find tutorials, samples, technical articles, and downloadable
tools.

-----Original Message-----
From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si]
Sent: Wednesday, November 10, 1999 2:54 AM
To: 'Alan Menezes'; xml-dev@ic.ac.uk
Subject: RE: MSXML help


There is help for MSXML on MSDN (best if you have it on CD), but there are
no items related to this topic in index, so you just have to do a full
search (e.g. try IXMLDOMNode, and from there you'll be able to come to all
the rest through links).

-----Original Message-----
From: Alan Menezes [mailto:AlanM@SYNECTICS.Soft.net]
Sent: Wednesday, November 10, 1999 5:54 AM
To: xml-dev@ic.ac.uk
Subject: MSXML help



Hi all,
Can soembody tell me where i can get documentation for MSXML COM component.
I want details on the Interfaces and Methods.
thanks,
Alan


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



From l-arcini at uniandes.edu.co  Fri Nov 12 00:07:29 1999
From: l-arcini at uniandes.edu.co (Fabio Arciniegas A.)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <382B4113.87465044@infinet.com>
Message-ID: <000801bf2ca1$66c7f340$0100000a@phoebe>

- ...
-o No non-character entity references
-o No predefined character entities (I am iffy on this one)
- ...

- What do you guys think?

I think It is true that it saves a lot of work (at expenses of some features
that i confess i like, e.g attributes), therefore making it possible to use
smaller, faster parsers. But I would be a bit concerned about
interoperability  issues...

I think that in order to keep things interoperable, it could be an
"optimizing choice" for an application to use an "SML parser". The process
would be something like having the app ready for XML parsing and then when
faced with a PI(? -maybe something else-) stating that this is SML,
switching parsers...
But only as a convinient runtime choice. Implementing an application that
*only* manages SML wouldn't seem convenient to me in many important respects
like interoperability and extensibility...

- ...
-o No Attributes (ouch!)
-o No PI, Comments, Notations, or CDATA sections
-o No document type declaration
-o UTF-8 encoding only
- subject to change later depending on your capacity to scream
convincingly.  The key point to consider is whether there is
a broad enough need for such a subset of 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From anderst at toolsmiths.se  Fri Nov 12 00:09:45 1999
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:16:51 2004
Subject: XML Schema enum and boolean
Message-ID: <382AB73F.52A0F0AE@toolsmiths.se>

Food for thoughts:

Add a bindings concept to XML schema to handle boolean ,
enumeration data types and language issues.

An binding is a sequence of pairs of value space expression and lexical
representation
where each value space expression must express a subspace (or equal) of
the
data types value space. The order of the pairs is important since it
defines a confliction
resolution order.


Examples:
<datatype name=?boolean?>
  <basetype name=?integer?/>
    <minInclusive>0</minInclusive>
    <maxInclusive>1</maxInclusive>
</datatype>

<datatype name=?myBoolean?>
    <basetype name=?boolean?/>
   <binding>
     <bind><value> 1 <value>  <pattern> [Tt][Rr][Ue][Ee]</pattern>
</bind>
     <bind><value> 0 <value>  <pattern> [Ff][Aa][Ll][Ss][Ee] </pattern>
</bind>
     <bind><value> 1 <value>  <literal> on </literal> </bind>
     <bind><value> 0 <value>  <literal> off </literal> </bind>
   </binding>
</datatype>

<-- Here the value space is the same but more acceptable lexical resp.
-->
<datatype name=?mySwedishBoolean?>
    <basetype name=?myBoolean?/>
  <binding>
     <bind><value> 1 <value>  <literal> sant </literal> </bind>
     <bind><value> 0 <value>  <literal> falskt </literal> </bind>
   </binding>
</datatype>

<-- Enumeration -->
<datatype name=?enum?>
  <basetype name=?integer?/>
</datatype>

<datatype name=?myByteColor?>
  <basetype name=?enum?/>
    <minInclusive>0</minInclusive>
    <maxInclusive>255</maxInclusive>
 <binding>
     <bind><value> 0 <value>  <literal> white </literal> </bind>
     <bind><value> 255 <value>  <literal> black </literal> </bind>
   </binding>
</datatype>

<datatype name=?mySwedishByteColor?>
  <basetype name=?myByteColor?/>
 <binding>
     <bind><value> 0 <value>  <literal> vit </literal> </bind>
     <bind><value> 255 <value>  <literal> svart </literal> </bind>
   </binding>
</datatype>


Thanks
/Anders
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/  Financial Toolsmiths AB  /
/  Anders W. Tell           /
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



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



From liamquin at interlog.com  Fri Nov 12 01:17:07 1999
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <Pine.BSI.3.96r.991111192600.15816B-100000@shell1.interlog.com>

There was a "tinyxml" proposal, I think by Dan Connolly but I
might have misremembered, during the development
of XML.  I had hoped it would succeed, but the overall
feeling was that we had to have a single unified front,
no optional XML features.  I think that was the
right decision.

On the other hand, there are a number of features in XML that
at the time I opposed, or that I now wish I had opposed :-)

Water under the bridge collects in stagnant pools at times,
as len might say I suppose :)

I've contributed some ideas below, and I think in some ways they
are closer to whatthe XML WG might have come up with had namespaces
and schema proposals been around at teh time, and  had the concept of
getting rid of so many featuers been a feasible one.


On Thu, 11 Nov 1999, Don Park wrote:
> o No Attributes (ouch!)
almost, see below
> o No PI, Comments, Notations, or CDATA sections
agreed 100%
> o No document type declaration
OK..
> o UTF-8 encoding only
hmmm, Latin 1is useful thouugh.   Not sure on this one,
but I could be convinced.
Agreed -- they are pretty poorly defined anyway, if you read
the spec carefully.
> o No non-character entity references
> o No predefined character entities (I am iffy on this one)
You need a way to escape & < and > so maybe these are worth
keeping.  However, seem y comments below.

I would like to suggest a convention for using a
minimum subset of XML, so that all "SXML" documents would also be
well-formed XML documents, and, with the addition of
a DTD or Schema, could be valid.

One way to do this would be to define your own element and name space:
SXML, say.

Suppose that an SXML document had a head and a body, but that the body
could contain whatever XML you wanted.

The head would contain, optionally,
* definitions of repeated fragments
* metadata about the document
* an optional reference to a Schema, so as not to have
  to use processing instructions or comments
* an optional erference to one or more style sheets, again
  avoidig these silly processing instructions

All the references would use XLink, unless XLink  ends up not supporting anything as
simple as an href attribute, in which case you might as well
use an href attribute.

Getting rid of DOCTYPE means you have no way to define yuor own entities,
and in that case might as well get rid of the entity mechanism
altogether.
For inclusion, use id/idref topoint to an object defined
in the header:
<SXML:HEAD>
 <SXML:OBJECT NAME="Gribble">My name is Gribble</SXML:OBJECT>
</SXML:HEAD>
<SXML:BODY>
 <P>Ths is Gribble. <SXML:USE WHAT="Gribble" /> </P>
</SXML:BODY>

An SXML parser wold not need to understand namespaces, only to allow
colon (:":) in identifiers.

Lee

--
Liam Quin, Barefoot Computing, Toronto;  The barefoot agitator
liam at holoweb.net [note changed address]
Ankh on irc.sorcery.net, http://www.valinor.sorcery.net/~liam/


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 01:18:06 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:16:51 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
 <4.2.0.58.19991110132052.00d0bf00@pop1.attglobal.net>
 <4.2.0.58.19991111101704.00b58830@pop1.attglobal.net>
Message-ID: <382B6AD0.FC49B32F@isogen.com>

"G. Ken Holman" wrote:

> 
> I do *not* use external parsed entities for an information sharing scheme
> ... I use any one external parsed entity as a convenience in only one
> instance and don't "use them with other chunks".

Ken is an example of a well-informed, careful user who understands his
tools and uses them appropriately. He is a professional. He is rare in
that regard.

As Ken points out, when used safely, external unparsed entities are
useful. Just like those eight-foot chainsaws professional lumberers use.

> Yes, I can understand those who don't want to give users enough rope to 
> hang themselves, but I don't think we can legislate all barriers to 
> abuse.  Certainly it behooves us who work with this technology to preach 
> that external parsed entities are unacceptable for fragment reuse (thank 
> you, Eliot, for doing so publicly), but if people won't listen, is that the 
> design's fault?  Does the feature *have* to disappear?

I can certainly appreciate this position, but in the XML context, given
that our primary design principle was "simplify", I felt that the loss
of external unparsed entities would have provided a signficant
simplification benefit at a minimal loss of function while forcing
people to come to the understanding that Ken demonstrates above, an
understanding they had, to that point, seemed to be quite unwilling to
come to, for whatever reason.

I suspect that once we have infrastructure that makes working with
complete documents as convenient as working with external parsed
entities that we will see the use of external parsed entities naturally
fall away.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 01:51:57 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: "Michael Champion"'s message of "Thu, 11 Nov 1999 16:56:05 -0500"
References: <000201bf2c4b$6a56b560$099918d1@docuverse1> <m3bt91hr4f.fsf@localhost.localdomain> <001301bf2c8f$8f202fe0$04d88dce@PTGRESTON>
Message-ID: <m33duciil9.fsf@localhost.localdomain>

"Michael Champion" <Mike.Champion@softwareag-usa.com> writes:

> Perhaps, but just as XML inself sprang from a concern that the SGML standard
> was far too complex for Web applications, I'm seeing increased concern that
> the XML standards are getting too complex, and the standards processes too
> slow moving,  to really meet the needs of e-business. 

Sure, I'm hearing the same thing, but the complaints aren't about the
XML 1.0 Syntax, they're about the related work in schemas, linking,
etc.  Creating a new, variant XML syntax won't help much with any of
that.

> > Even if the separate dialect is a pure subset, it will still split the
> > XML market for no good reason
> 
> I guess the reason why I'm intrigued by Don Park's proposal is that it seems
> to me (especially having made a career move from a text/publishing XML
> vendor to an enterprise commerce XML vendor)  like there *is* a good reason
> for considering whether the set of XML features needed by e-business
> applications is massively smaller than the set needed by text
> authoring/publishing/browsing applications.

But people writing that kind of application don't much care about the
fact that the XML parser they're using happens to support PIs or
notations -- sure, the parser's maybe 5% larger than it would be
without that stuff, but that's a lot better than software based on
some other specs and standards.

> > That said, it's certainly useful to define APIs that hide some of that
> > stuff -- applications should not have to worry about unparsed
> > entities, notations, etc. unless they want to
> 
> Right.  Maybe the "SML" idea would meet less resistance if it referred to
> XML processing tools and APIs that quietly ignored some well-defined set of
> legal XML constructs (attributes, comments, PIs, notations, entities, or
> whatever) in well-formed XML documents rather than defining a subset of XML
> itself in which these are illegal. I think that's well within the spirit of
> both Don's posting and the "less is more" perspective in the xml.com
> articles mentioned above.

But you can do that already.  With SAX, it's trivial: just don't call
Parser.setDTDHandler and implement
DocumentHandler.processingInstruction as an empty method:

  public void processingInstruction (String target, String data)
  {
    // I don't care.
  }

If you're inheriting from HandlerBase, you don't even have to do
that.

What we need (and perhaps what you and Don are getting at) is for
individual applications to make declarations like

  XHTML user agents will ignore processing instructions.

Sure, why not?  It won't hurt much, though there might be some
complications when we start mixing vocabularies.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 03:35:47 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:51 2004
Subject: XML 2.0alpha specification released! (Re: external parsed entites (was: A unique ID question ?))
References: <003701bf2c02$52861960$1bf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <382B89DC.1910@hiwaay.net>

Rick Jelliffe wrote:
> 
> From: W. Eliot Kimber <eliot@isogen.com>
> 
>  >> External parsed entities are a done deal for XML 1.0.
> >> But hey, just a version number, right?  We get to
> >> have this fight again. :-)

Don't blame Eliot for saying that.  He just wants it.  The 
Cat In The Hat said That.

> I am happy to announce the release of the XML 2.0alpha specification. It
> has been created by using all the criticisms of XML over the last year.

Your specification and list of commentors is brilliant.  Five 
stars for wit and an astounding memory. *****

Different issue:  Can someone explain to me why arrays have 
been removed from the XML schema datatypes?  Thing One 
and Thing Two are working on an XML binding.  They say they need 
those and without them, XML schemas don't work for the 
application.  Soooo, please, some non-secret-revealing 
discussion would be most appreciated.  I'll even drop 
the cat 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 03:35:25 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
References: <Pine.LNX.4.10.9911111724530.10778-100000@cantor.clarkevans.com>
Message-ID: <382B87A8.5D01@hiwaay.net>

Clark C. Evans wrote:
> Sounds like many many people are using XML
> in this way *anyway* -- why not give it
> a name?

Because you will need a name to name the name 
you name it.  Gets complex fast.  Standards 
work like that.  Profiles too.  Putting the cat 
in the bag was hard enough.  Want to face a mad 
cat?  Take him out again.

The contract you need in this case is not an 
XML variant.  You need a conformance spec for 
a system design that limits the feature set.  That way, 
you get what you contract for and the market does 
not get confused.

Battle scarred Cowardly Lion



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 03:35:21 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
References: <A51F7543E295D2118D6600A024CDB2F71B9CB9@MAILPROD> <m366z8j55g.fsf@localhost.localdomain>
Message-ID: <382B84FB.5D2B@hiwaay.net>

David Megginson wrote:
> 
> Vane Lashua <vlashua@RSGsystems.com> writes:
> 
> > That's what a dtd is for!
> > It's the contract!
> 
> A DTD is a contract for structure, not for features.  

And names.  Don't forget the names.  But Vane has the right idea 
as long as he remembers a lot of the contract was in the comments. 

Now, give us schemas so we can make the bloody contracts a bit 
more negotiable and a little less time sensitive. It is an 
interesting thought experiment.  Construct a generic schema, 
then see if multiple (ahh... two) business processes can negotiate a 
schema by which other processes will exchange objects, messages, 
etc.  Start with a seed schema so the DOM has something to 
munch on, and come up with the simplest system of seed 
messages to start the negotiation.  The negotiating processes 
can build any number of intermediate versions as long as 
they don't need human intervention.  Fine contest or thread 
for folks bored about external entities.  Wow those venture 
capitalists and scare some CEOs right out of their options.

> Battle-scarred
> SGML veterans will remember the SGML declaration, which was the
> contract for what features need to be supported by both ends ("I
> promise not to use names longer than 8 characters", etc.).  The SGML
> declaration was first against the wall when the XML revolution came.

Ain't it the truth! well... there is one there but it has been *fixed*. 
I am not complaining because explaining it was usually pretty 
tough, but there were some fun things you could do like limit
recursions.

The Cowardly Lion



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 03:51:11 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:51 2004
Subject: A unique ID question ? (was: external parsed entites) 
References: <3.0.32.19991109165751.014f6360@pop.intergate.ca>
	 <4.2.0.58.19991110132052.00d0bf00@pop1.attglobal.net> <4.2.0.58.19991111101704.00b58830@pop1.attglobal.net>
Message-ID: <382B8DC2.1D00@hiwaay.net>

G. Ken Holman wrote:
> 
> Yes, I can understand those who don't want to give users enough rope to
> hang themselves, but I don't think we can legislate all barriers to
> abuse.  

We can try.  If we get rid of the rope makers, we can get rid 
of the hangings.  Seems to be the way the tobacco legislation 
is going on this side of the falls.

> Certainly it behooves us who work with this technology to preach
> that external parsed entities are unacceptable for fragment reuse (thank
> you, Eliot, for doing so publicly), but if people won't listen, is that the
> design's fault?  Does the feature *have* to disappear?

Of course not.  It just has to be defended from time to time by a 
reasonable user with a reasonable and well-stated requirement.  
Thanks, Ken.  

I take Eliot and Tim very seriously, and if they 
want it out, I want to know why.  I understand the reference 
bear.  To me, the general entities are not as useful as they once were, 
but for those that know how, understand their limits, and 
apply them accordingly, they are safe.  I can remember when 
PIs were despised too, and darn, they got a new career after 
the revolution.  Soo..

Now that unique ID thing and namespaces?  Something about hats? 
Does everyone feel comfortable about the problems with ID/IDREFs 
and aggregate documents? Our only solution for X3D is to keep 
the Protos and Inlines in tightly sealed bags.   Is it the 
case that if we use IDs and IDREFs, we don't have any way 
of ensuring their unique relationships if X3D is used with 
an XHTML host?  

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Fri Nov 12 04:38:46 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:16:51 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <Pine.LNX.4.10.9911111718060.10778-100000@cantor.clarkevans.com>
Message-ID: <000301bf2cc7$9d5c7720$3a7370c6@eps.inso.com>

> I've always been afraid of external entities.  
> Do you have some examples you can share?

Have a look at the DOM specification!


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



From jelks at jelks.nu  Fri Nov 12 05:10:25 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:51 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <Pine.LNX.4.10.9911111724530.10778-100000@cantor.clarkevans.com>
Message-ID: <NBBBICMNIPCICMKJECCBKEIEDBAA.jelks@jelks.nu>

Clark Evans wrote:

> > o UTF-8 encoding only
>
> I'm kinda ingnorant... would it still be
> possible to handle oriental character sets
> with UTF-8 ?

Yes.  ASCII characters in UTF-8 only take up 1 byte, but if you're using
oriental character sets, one *character* can take up several bytes.  I forget
the max number and the algorhythm used, but I bet some other folks here would
know.  The only problem is when an *entire* oriental character set document is
in UTF-8, then it's liable to be bigger than one encoded in UTF-16, where you
know that every character will take up two bytes, no more, no less.

> > o No non-character entity references
> > o No predefined character entities (I am iffy on this one)
>
> Sure.

How are you going to handle < and & in PCDATA, unless you declare them
explicitly (which is hard to do when you've done away with the DOCTYPE
declaration)  ...


/Jelks


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 05:20:34 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:52 2004
Subject: external parsed entites (was: A unique ID question ?)
References: <000301bf2cc7$9d5c7720$3a7370c6@eps.inso.com>
Message-ID: <382BA39B.A83ADDD3@pacbell.net>

Gavin Thomas Nicol wrote:
> 
> > I've always been afraid of external entities.
> > Do you have some examples you can share?
> 
> Have a look at the DOM specification!

[ that is, its source -- follow the production notes at the end
of the spec ]

Or the 1913 Websters Dictionary, about 30 entities of 1.5 Mbytes
each, http://metalab.unc.edu/webster/ ... and I'd hate to ever
see that turn into one 55 MByte file!

On a smaller scale, Joseph Conrad's "Heart of Darkness" is
online at http://www.megginson.com/texts/darkness/index.html

Surely there are more.  Nothing to be afraid of with a tool
that's used appropriately!

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Fri Nov 12 05:32:18 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:16:52 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <Pine.BSI.3.96r.991111192600.15816B-100000@shell1.interlog.com>
Message-ID: <NBBBICMNIPCICMKJECCBCEIFDBAA.jelks@jelks.nu>

Liam R. E. Quin wrote:

> Suppose that an SXML document had a head and a body, but that the body
> could contain whatever XML you wanted.
>
> The head would contain, optionally,
> * definitions of repeated fragments
> * metadata about the document
> * an optional reference to a Schema, so as not to have
>   to use processing instructions or comments
> * an optional erference to one or more style sheets, again
>   avoidig these silly processing instructions

I think this is actually going to be called "XML Packaging".  I say "think",
because the W3C has not officially described what XML Packaging is to include,
but several members have said that it should include the above.

> <SXML:HEAD>
>  <SXML:OBJECT NAME="Gribble">My name is Gribble</SXML:OBJECT>
> </SXML:HEAD>
> <SXML:BODY>
>  <P>Ths is Gribble. <SXML:USE WHAT="Gribble" /> </P>
> </SXML:BODY>
>
> An SXML parser wold not need to understand namespaces, only to allow
> colon (:":) in identifiers.

Yeah, but those colons turn SXML into CXML ...  :

/Jelks


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



From gtn at ebt.com  Fri Nov 12 05:45:54 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:16:52 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <382BA39B.A83ADDD3@pacbell.net>
Message-ID: <000e01bf2cd1$21d00090$3a7370c6@eps.inso.com>

> Or the 1913 Websters Dictionary, about 30 entities of 1.5 Mbytes
> each, http://metalab.unc.edu/webster/ ... and I'd hate to ever
> see that turn into one 55 MByte file!
> 
> On a smaller scale, Joseph Conrad's "Heart of Darkness" is
> online at http://www.megginson.com/texts/darkness/index.html
> 
> Surely there are more.  Nothing to be afraid of with a tool
> that's used appropriately!

Exactly. I was one of the XML WG members that argued for entities
very strongly... mostly because from my experience, they are 
very useful. 

SGML external entities are far more dangerous... they allow 
things that wouldn't even be well-formed XML entities (makes
database management of SGML *hard*). Even then, I have built 
systems that used entities as the primary object of reuse
(mostly publishing systems) and they worked fine... because
entities were largely transparent to the uninitiated.

The most radical thought I had for use of entities was in the
content of SMIL-ish things, where you might want to broadcast 
an XML/XHTML document. You could use entities to decompose a
document into chunks < 512 bytes each, and incrementally recompose 
the document in the receiver. This would require a default
entity resolution mechanism for undelcared entities to work
well... I proposed something like that to the XML WG if I
remember correctly...



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



From clark.evans at manhattanproject.com  Fri Nov 12 05:59:07 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:16:52 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <NBBBICMNIPCICMKJECCBCEIFDBAA.jelks@jelks.nu>
Message-ID: <Pine.LNX.4.10.9911120100370.12510-100000@cantor.clarkevans.com>

On Fri, 12 Nov 1999, Jelks Cabaniss wrote:
> Yeah, but those colons turn SXML into CXML ...  :

And I thought the evening was going to be humorless...

Clark



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 06:11:06 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:52 2004
Subject: XML Schema and international Booleans
Message-ID: <00f501bf2cd8$1feb84f0$15f96d8c@NT.JELLIFFE.COM.AU>


From: Anders W. Tell <anderst@toolsmiths.se>

Rick Jelliffe wrote:

>  From: Anders W. Tell <anderst@toolsmiths.se>

> Then I have a hard time to understand why they are using highly
flexible
> value-space, lexical-representation concepts and then don't use them,
as in
> the case of boolean.

The best practical steps you should take are
    1) come up with a little complaint, an alternative proposal and
justification
    2)post this to the comment mailing list at W3C
    3) also, notify the w3c i18n WG that you think the approach is
wrong.
Your comment might be particularly appropriate at this time.

The other thing to consider is that XMl Schemas 1.0 is already looking
late: I would prefer they leave out value renaming until XML Schemas 2.
I think the main purpose of XML Schemas 1.0 should be to provide the
basic datatyping rather than class or subtyping mechanisms, but I think
most people want more from the base-level XML Schema 1.0

 > ISO creates international standards and im pretty sure that
{true,false} is not
> internationally accepted. Using zero (0) and one (1) is certainly more
neutral and
> logical.

No, because 0 and 1 do not carry implications of true or false to many
people.  And 0 and 1 are Western symbols, so they are only slightly more
"international" than "true" and "false". Also, don't forget that O is
used for "approve" and X is used for "disapprove" in some countries, so
some people may expect 0 to mean "true".

> Frankly Im surprised that it appears that Internationalization is not
accepted
> by all parties involved in writing and debating international
standards.

Well, the problem is that localization is not accepted by all!

> And why should I be forced to use english as a norm ? Why not Swedish
> or Esperanto, which is supposed to be the most universal language of
them all.

Have you seen Euorpanto?  It is a fake language made by EC translators:
you can use any word from any European language with any order allowed
in any European language: Ik laugh pour ein solche new language
doloroso.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 06:38:29 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:52 2004
Subject: XML and SML
Message-ID: <013b01bf2cdb$e309bf30$15f96d8c@NT.JELLIFFE.COM.AU>

 
From: James Robertson <jamesr@steptwo.com.au> 

>An open letter to Rick Jelliffe,
 
>However, I don't think you expected
>it to be the catalyst for just such
>a "cut down" proposal just hours later!
 
Yes, in the future everyone will be on the XML WG for
fifteen minutes. 

Let us not forget that LISP S-expressions (parenthesis)
have been around for 35 years; they are simple and can be
used for markup, but they didn't take off for that use.  
And Borenstein has that RFC on a markup language that 
is simpler than XML and just used elements: it has been 
around for ages and has gone nowhere for documents. 

I think the internationalization in XML is one of the major reasons
larger companies like it: it provides an integration 
path from current encodings to Unicode--people who
think it is now time to have only UTF-8 have their heads 
in the sand: so we need encoding headers & NCRs & 
attributes (to support language) as a minimum requirement
for i18n IMHO. 

If there is a strong need for a simpler markup language,
I think it needs to target a particular issue in which XML
is weak: difficulty of implementation just isn't one of them.
Who are these poor implementers of parsers we need to be
so concerned about: IBM? Sun?  Microsoft? James Clark 
has not conspicuously favoured simple software projects.

In what way is it simpler to make up a new markup language, 
document it, write a parser and API for it, compared to using
XP or one of the Java parsers?  The area where there is scope
for a new markup language is for large tables of fielded data
in which every field is the same: now I know that compression
takes care of this really, but some people still freak out when they 
see markup: *but* there is a recent RFC  this month on such
a language.  It is a nice language, but if you compare it to XML
you can see the maturity of the SGML/XML community
in comparison.

The debate about a simpler XML is just a waste of time.
Where are the people debating about a simpler XML Schema
proposal!  That is something where people might have some
impact?  Anders and Len are doing something useful bringing
up these schema issues. With all respect, but I hope that people
who want SML should move to SML-DEV: I already get over
200 emails a day. Jokes are welcome but not farces.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Wdehora at cromwellmedia.co.uk  Fri Nov 12 09:08:05 1999
From: Wdehora at cromwellmedia.co.uk (Bill dehOra)
Date: Mon Jun  7 17:16:52 2004
Subject: Why do we write standards?
Message-ID: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>


    :  To summarize more briefly, I suggested that there are 
    :  two paths to
    :  standardization (which we all agree is a good thing):
    :  
    :  1. The big-bang approach, where we try to do everything 
    :  at once and
    :     either fail or succeed spectacularly.
    :  
    :  2. The incremental approach, where we do a little at a 
    :  time without
    :     getting too far ahead of implementors.
    :  
    :  Both of these head for the same place, but I think that 
    :  (1) has failed
    :  so often during the 1990s (i.e. every W3C attempt at an 
    :  HTML standard)
    :  that we should think harder about (2).
    :  

There is another aspect to standardisation. That is acceptance of the
standard. It's not enough to get together and generate standards and only
worry about rates of development. The standard must be easily implemented.
This, I think is the reason IP and HTTP were accepted: they were relatively
simple protocols to implement. To get a standard accepted, ease of
implementation needs to be designed in, that is, complicated, hard to use
standards are in some sense invalid. I see some standards that are verging
on the Baroque. CSS comes to mind, maybe CORBA. CSS is way ahead of anything
anyone is implementing right now and the features are being piled on for
CSS3. 

Obese standards are invalid.

Ease is desirable because it allows people to get things done. I worry about
XML, when I see 'added extras' like metadata, namespaces, XSL, CSS, XLink
crawling out of the woodwork. Not that the goal of these standards isn't
desirable. But they serve to make XML complicated and difficult to
implement.

Regards,

Bill de hOra

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 11:01:36 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:52 2004
Subject: SML answers for SML problems
Message-ID: <001601bf2cfd$7cee4000$099918d1@docuverse1>

There were many points raised in the initial discussion of
the SML idea:

1) Smaller and faster

I think everyone can agree that SML parsers will be smaller
and faster than XML parsers due to removal of features.  What
remains controversial is whether the difference is significant
enough to justify SML.  Since we do not have SML parsers to
compare XML parsers with, we are left with only extrapolations
and guessworks.

My assessment is that the difference is not significant for
general XML applications.  However, the difference is important
for XML applications that places a high premium on size and/or
speed.  On appliance-level devices, even 5K difference in size
translates to significant manufacturing cost increase because
memory size does not increase in friendly increments.  On network
routers and proxies, even a few microseconds delay can mean
significantly reduced load capacity.  There are no talk of
'documents' on these type of applications.

2) Simpler and easier

Based on my experiences in 'spreading the XML religion', I
find that XML is easy to learn but it is hard to learn
completely.  Key ideas behind XML is strikingly simple yet
most people get confused by things like DTD, PI, notation,
comment, entity, XML declaration, whitespace rules, character
encoding, etc.

One of the goals for SML should be:

    SML is what people think XML is.

By people, I mean the engineers understand the key concepts
behind XML but have not yet been spoiled by the hairy details.
SML should fit the mental model of XML people build when they
first hear about XML.

I believe that an engineer can not use a tool fully unless
he/she understands the tool completely.  Perhaps it is a
peace of mind, perhaps it is confidence.  Whatever the reason,
it is important that there is a clear mental picture of the
tool and its capabilities.  Having a clear spec is great but
having to refer back to it frequently is not good in my book.

SML will be simpler and easier to learn completely.  Question
is whether there is truely a need for simpler and easier XML.

3) Data versus Documents

A good part of XML 1.0 is designed to address document
processing problems.  Those parts fails to apply when XML data
exists only in transit (WebDav, XML-RPC, SOAP), has no end
(continuous broadcast), or is sent one-way only.  While the spec
for such applications might list the unsupported features of XML,
I believe it is easier to just say the spec uses the SML subset.

4) Friend or foe?

Is SML a friend or foe of XML?  Many folks brought up this
question either directly or indirectly.  I happen to think
SML will eventually help rather than hurt adoption of XML but
the media might have a field-day with SML vs. XML articles.

My thought at this point is that SML is needed by a subset of
the XML community.  Creating a subset of XML for subset of XML
community seems like a reasonable thing to do.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From asjoshi at hss.hns.com  Fri Nov 12 11:20:06 1999
From: asjoshi at hss.hns.com (asjoshi@hss.hns.com)
Date: Mon Jun  7 17:16:52 2004
Subject: Need help on converting WML to WBXML
Message-ID: <65256827.003DBA4B.00@sandesh.hss.hns.com>



Hi all!!

I do not know if this question belongs to this newsgroup.. but here it is
anyway..

For a prototype, we need a WML to WBXML converter.. that can be run standalone
(ie is not part of a larger toolkit )

Any pointers on where I can find one??

Ashutosh



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 11:51:17 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:52 2004
Subject: SML answers for SML problems
In-Reply-To: "Don Park"'s message of "Fri, 12 Nov 1999 03:02:57 -0800"
References: <001601bf2cfd$7cee4000$099918d1@docuverse1>
Message-ID: <m3zowkgc8g.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> There were many points raised in the initial discussion of
> the SML idea:
> 
> 1) Smaller and faster
> 
> I think everyone can agree that SML parsers will be smaller
> and faster than XML parsers due to removal of features.  What
> remains controversial is whether the difference is significant
> enough to justify SML.  Since we do not have SML parsers to
> compare XML parsers with, we are left with only extrapolations
> and guessworks.

And anecdotal evidence.  I've mentioned my own experience with
AElfred, which was a recursive descent parser.  Since the lexical
routines for reading names, etc. already had to be in place, handling
PIs and stuff like that was trivial.  Here's what Matt Timmerman's
current version has:

  void parsePI ()
    throws java.lang.Exception
  {
    String name;

    name = readNmtoken(true);
    if (!tryRead("?>")) {
      requireWhitespace();
      parseUntil("?>");
    }
    if (handler != null) {
      handler.processingInstruction(name, dataBufferToString());
    }
  }

> My assessment is that the difference is not significant for
> general XML applications.  However, the difference is important
> for XML applications that places a high premium on size and/or
> speed.  

Even on an embedded system, I doubt that the few bytes added by the
above example would amount to anything -- of course, a parser
implemented as a state machine might need more or less overhead.

The support for attributes is a little longer, but not all that much.
We're not talking about 5K here -- that comes from detecting all of
the well-formedness errors required for conformance and storing the
text of their messages.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 11:56:09 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:52 2004
Subject: XML and SML
In-Reply-To: <013b01bf2cdb$e309bf30$15f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000001bf2d05$2bf005a0$099918d1@docuverse1>

Rick,

>Let us not forget that LISP S-expressions (parenthesis)
>have been around for 35 years; they are simple and can be
>used for markup, but they didn't take off for that use.  
>And Borenstein has that RFC on a markup language that 
>is simpler than XML and just used elements: it has been 
>around for ages and has gone nowhere for documents.

LISP S-expressions is definitely not XML.  Is And Borenstein's
markup language XML?  SML is and I believe it makes a difference.

>I think the internationalization in XML is one of the major
>reasons larger companies like it: it provides an integration 
>path from current encodings to Unicode--people who
>think it is now time to have only UTF-8 have their heads 
>in the sand: so we need encoding headers & NCRs & 
>attributes (to support language) as a minimum requirement
>for i18n IMHO.

That is great for the larger companies.  They can use the full
XML and so will I for applications where i18n is a key factor.
I don't mind using UTF-8 for those occasional foreign characters
so there is no conflict.

Now, why would you mind if I used a simple subset of XML features
and gave it a name?  I do not see how that hurts those large
companies.

>If there is a strong need for a simpler markup language,
>I think it needs to target a particular issue in which XML
>is weak: difficulty of implementation just isn't one of them.
>Who are these poor implementers of parsers we need to be
>so concerned about: IBM? Sun?  Microsoft? James Clark 
>has not conspicuously favoured simple software projects.

Try cramming full a XML parser into a toaster.  When you
got some space left, throw in a compression library as well.

>In what way is it simpler to make up a new markup language, 
>document it, write a parser and API for it, compared to using
>XP or one of the Java parsers?  The area where there is scope
>for a new markup language is for large tables of fielded data
>in which every field is the same: now I know that compression
>takes care of this really, but some people still freak out when they 
>see markup: *but* there is a recent RFC  this month on such
>a language.  It is a nice language, but if you compare it to XML
>you can see the maturity of the SGML/XML community
>in comparison.

You can still use XP or one of the Java parsers to parse SML since
it is XML.  I don't see where this argument is going.

>The debate about a simpler XML is just a waste of time.
>Where are the people debating about a simpler XML Schema
>proposal!  That is something where people might have some
>impact?  Anders and Len are doing something useful bringing
>up these schema issues. With all respect, but I hope that people
>who want SML should move to SML-DEV: I already get over
>200 emails a day. Jokes are welcome but not farces.

I don't think the SML discussion is taking attention away
from XML Schema discussions.  Why all the hostility, Rick?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From costello at mitre.org  Fri Nov 12 13:19:28 1999
From: costello at mitre.org (Roger L. Costello)
Date: Mon Jun  7 17:16:52 2004
Subject: XSL Tutorial
Message-ID: <382C1432.144E272@mitre.org>

Hi Folks,

I have updated and expanded my XSL tutorial.  The tutorial is for the
latest spec (Oct. 8).  It includes two Powerpoint presentations (about
150 slides), 29 complete, working examples, and a run.bat file to run
the examples.  The examples use James Clark's XSL Processor, XT[1].  The
tutorial is at:

<http://www.xfront.org/xsl.html>

I hope that you find it helpful.  /Roger

[1] <http://www.jclark.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 13:47:19 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun  7 17:16:52 2004
Subject: Why do we write standards?
In-Reply-To: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.
 co.uk>
Message-ID: <3.0.1.32.19991112084550.008c94a0@tiac.net>

>The standard must be easily implemented.
>This, I think is the reason IP and HTTP were accepted: they were relatively
>simple protocols to implement.

Nonsense.  IP never existed on it's own, IP was part of TCP/IP from the
outset, and TCP/IP is a pretty complicated beast.  It took years to get it
tuned right.  HTTP isn't all that easy either: it takes a few hundred lines
of hell to make a robust client that handles the myriad error conditions
and all the versions.  I've never written an HTTP server, but I can't
imagine it's all that trivial either.

No, the reason these were accepted was that good, working source code was
made freely available to all comers, and they met a very real need.  It
also helped that the IETF's policy is that you cannot make it up the RFC
food chain until there are two separate interoperable implementations of
the standard.  (If W3C required just one working implementation it would be
a quantum improvement of the process.  It's a great way to fight the
natural tendency for bloat.)

(Speaking of which, I just learned that the math which drives MP3 encoders
is patented!  You can get the source code for MP3 from ISO, but you have to
agree not to compile it!  How nuts is that?  It's GIF all over again!)

-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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Chris_Pacetti at whittman-hart.com  Fri Nov 12 14:47:04 1999
From: Chris_Pacetti at whittman-hart.com (Chris_Pacetti@whittman-hart.com)
Date: Mon Jun  7 17:16:52 2004
Subject: unsubscribe
Message-ID: <86256827.0050D7DC.00@mail.whittman-hart.com>



unsubscribe



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



From vlashua at RSGsystems.com  Fri Nov 12 15:06:38 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:52 2004
Subject: XML and SML
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CC4@MAILPROD>

The hostility is probably from a continuing frustration with economics and
common sense. SGML has been around for 15 years. A committee from the
Association of American Publishers met with the MS Word product manager at
the First MS CD-ROM conference (remember that?-- Internet World will go the
way of the CD-ROM conference one of these days) about implementing "simple"
SGML in MS Word and to use the AAP's recently developed Book, Journal, and
Magazine dtds. After all, Word had practically invented "styles" which
practically implemented GML which blah blah blah. It obviously didn't
happen.

Now Office 2000 is promising (still promising!) to use XML as an interchange
standard. Even with the bloat required to support Office 2000, the brains
don't seem to be in place to implement something that James Clark appears to
be able to do in his sleep, practically on a toaster.

There is computer power galore to implement full-blown SGML, XML, HTTP, a
browser and Unix in a toaster today. Would it (the computer power) even cost
$50? Would it even take 6 months to get it accomplished?

There are lots of ways to be a genius. Don't waste our Earth's resources
(your brain and energy) re-inventing something that will be out of date,
unnecessary, or simply out of gas in another 6 months.

Vane


-----Original Message-----
From: Don Park [mailto:donpark@docuverse.com]
Sent: Friday, November 12, 1999 6:58 AM
To: xml-dev@ic.ac.uk
Subject: RE: XML and SML


Rick,

>Let us not forget that LISP S-expressions (parenthesis)
>have been around for 35 years; they are simple and can be
>used for markup, but they didn't take off for that use.  
>And Borenstein has that RFC on a markup language that 
>is simpler than XML and just used elements: it has been 
>around for ages and has gone nowhere for documents.

LISP S-expressions is definitely not XML.  Is And Borenstein's
markup language XML?  SML is and I believe it makes a difference.

>I think the internationalization in XML is one of the major
>reasons larger companies like it: it provides an integration 
>path from current encodings to Unicode--people who
>think it is now time to have only UTF-8 have their heads 
>in the sand: so we need encoding headers & NCRs & 
>attributes (to support language) as a minimum requirement
>for i18n IMHO.

That is great for the larger companies.  They can use the full
XML and so will I for applications where i18n is a key factor.
I don't mind using UTF-8 for those occasional foreign characters
so there is no conflict.

Now, why would you mind if I used a simple subset of XML features
and gave it a name?  I do not see how that hurts those large
companies.

>If there is a strong need for a simpler markup language,
>I think it needs to target a particular issue in which XML
>is weak: difficulty of implementation just isn't one of them.
>Who are these poor implementers of parsers we need to be
>so concerned about: IBM? Sun?  Microsoft? James Clark 
>has not conspicuously favoured simple software projects.

Try cramming full a XML parser into a toaster.  When you
got some space left, throw in a compression library as well.

>In what way is it simpler to make up a new markup language, 
>document it, write a parser and API for it, compared to using
>XP or one of the Java parsers?  The area where there is scope
>for a new markup language is for large tables of fielded data
>in which every field is the same: now I know that compression
>takes care of this really, but some people still freak out when they 
>see markup: *but* there is a recent RFC  this month on such
>a language.  It is a nice language, but if you compare it to XML
>you can see the maturity of the SGML/XML community
>in comparison.

You can still use XP or one of the Java parsers to parse SML since
it is XML.  I don't see where this argument is going.

>The debate about a simpler XML is just a waste of time.
>Where are the people debating about a simpler XML Schema
>proposal!  That is something where people might have some
>impact?  Anders and Len are doing something useful bringing
>up these schema issues. With all respect, but I hope that people
>who want SML should move to SML-DEV: I already get over
>200 emails a day. Jokes are welcome but not farces.

I don't think the SML discussion is taking attention away
from XML Schema discussions.  Why all the hostility, Rick?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 15:24:04 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:16:53 2004
Subject: XML Schema and international Booleans
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16F7C@martinique>

> -----Original Message-----
> From: Rick Jelliffe [mailto:ricko@allette.com.au]
> Sent: Friday, November 12, 1999 12:32 AM
> 
>  > ISO creates international standards and im pretty sure that
> {true,false} is not
> > internationally accepted. Using zero (0) and one (1) is 
> certainly more
> neutral and
> > logical.
> 
> No, because 0 and 1 do not carry implications of true or false to many
> people.  And 0 and 1 are Western symbols, so they are only 
> slightly more
> "international" than "true" and "false". Also, don't forget that O is
> used for "approve" and X is used for "disapprove" in some 
> countries, so
> some people may expect 0 to mean "true".
> 

I may be mistaken about this, but I'm pretty sure that Boolean logic has
nothing to do with truth and falsity.  It just needs two distinguishable
values.  If we wanted to be really up-to-the-minute, we could follow the
usage of logicians and use U+22A4 (DOWN TACK) and U+22A5 (DOWN TACK) as the
canonical values (notice I didn't say "as 'true' and 'false'); but we would
be entirely justified in choosing "foo" and "bar".  Whether the booleans are
used to denote truth-values depends on the application, which should be able
to express t/f in any language.

I'm only half-joking about DOWN/UP TACK; DOWN TACK looks like a capital 'T',
UP TACK looks like it's opposite, so the mapping the true/false is
straightforward, but not part of the semantics of the symbols.  Also about
as language-neutral as it gets.  So define schema semantics in terms of
down/up tack, and define a few standard lexical mappings (e.g. to 'true' and
'false') that all implementations are required to understand.

My two cents before I head back to the fox hole.

-gregg

P.S.  I just love the phrase "international boolean".  We certainly don't
need no stinkin' national booleans.  Although I understand the municipal
booleans aren't bad in some places. ;)

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



From hpang at flycast.com  Fri Nov 12 15:34:57 1999
From: hpang at flycast.com (Hokkun Pang)
Date: Mon Jun  7 17:16:53 2004
Subject: SML answers for SML problems
Message-ID: <A7C924760A6BD311B97E0090271EB91047EA68@post.flycast.com>

duh, can't you come up with a better name?
SML is short for Standard Meta Language, which has be around for quite some
time
and holds a respected place in the computer science field.

> -----Original Message-----
> From:	Don Park [SMTP:donpark@docuverse.com]
> Sent:	Friday, November 12, 1999 6:03 AM
> To:	xml-dev@ic.ac.uk
> Subject:	SML answers for SML problems
> 
> There were many points raised in the initial discussion of
> the SML idea:
> 
> 1) Smaller and faster
> 
> I think everyone can agree that SML parsers will be smaller
> and faster than XML parsers due to removal of features.  What
> remains controversial is whether the difference is significant
> enough to justify SML.  Since we do not have SML parsers to
> compare XML parsers with, we are left with only extrapolations
> and guessworks.
> 
> My assessment is that the difference is not significant for
> general XML applications.  However, the difference is important
> for XML applications that places a high premium on size and/or
> speed.  On appliance-level devices, even 5K difference in size
> translates to significant manufacturing cost increase because
> memory size does not increase in friendly increments.  On network
> routers and proxies, even a few microseconds delay can mean
> significantly reduced load capacity.  There are no talk of
> 'documents' on these type of applications.
> 
> 2) Simpler and easier
> 
> Based on my experiences in 'spreading the XML religion', I
> find that XML is easy to learn but it is hard to learn
> completely.  Key ideas behind XML is strikingly simple yet
> most people get confused by things like DTD, PI, notation,
> comment, entity, XML declaration, whitespace rules, character
> encoding, etc.
> 
> One of the goals for SML should be:
> 
>     SML is what people think XML is.
> 
> By people, I mean the engineers understand the key concepts
> behind XML but have not yet been spoiled by the hairy details.
> SML should fit the mental model of XML people build when they
> first hear about XML.
> 
> I believe that an engineer can not use a tool fully unless
> he/she understands the tool completely.  Perhaps it is a
> peace of mind, perhaps it is confidence.  Whatever the reason,
> it is important that there is a clear mental picture of the
> tool and its capabilities.  Having a clear spec is great but
> having to refer back to it frequently is not good in my book.
> 
> SML will be simpler and easier to learn completely.  Question
> is whether there is truely a need for simpler and easier XML.
> 
> 3) Data versus Documents
> 
> A good part of XML 1.0 is designed to address document
> processing problems.  Those parts fails to apply when XML data
> exists only in transit (WebDav, XML-RPC, SOAP), has no end
> (continuous broadcast), or is sent one-way only.  While the spec
> for such applications might list the unsupported features of XML,
> I believe it is easier to just say the spec uses the SML subset.
> 
> 4) Friend or foe?
> 
> Is SML a friend or foe of XML?  Many folks brought up this
> question either directly or indirectly.  I happen to think
> SML will eventually help rather than hurt adoption of XML but
> the media might have a field-day with SML vs. XML articles.
> 
> My thought at this point is that SML is needed by a subset of
> the XML community.  Creating a subset of XML for subset of XML
> community seems like a reasonable thing to do.
> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From vlashua at RSGsystems.com  Fri Nov 12 16:04:28 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:16:53 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9CC5@MAILPROD>

And the comments become the human-readable schema.

-----Original Message-----
From: Len Bullard [mailto:cbullard@hiwaay.net]
Sent: Thursday, November 11, 1999 10:10 PM
To: David Megginson
Cc: xml-dev
Subject: Re: Feeler for SML (Simple Markup Language)


David Megginson wrote:
> 
> Vane Lashua <vlashua@RSGsystems.com> writes:
> 
> > That's what a dtd is for!
> > It's the contract!
> 
> A DTD is a contract for structure, not for features.  

And names.  Don't forget the names.  But Vane has the right idea 
as long as he remembers a lot of the contract was in the comments. 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 16:10:05 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:16:53 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <Pine.LNX.4.10.9911111724530.10778-100000@cantor.clarkevans.com>
References: <000201bf2c4b$6a56b560$099918d1@docuverse1>
	<Pine.LNX.4.10.9911111724530.10778-100000@cantor.clarkevans.com>
Message-ID: <14380.11614.10000.669791@menteith.com>

At 11 Nov 1999 17:32 -0500, Clark C. Evans wrote:
 > > o UTF-8 encoding only
 > 
 > I'm kinda ingnorant... would it still be
 > possible to handle oriental character sets
 > with UTF-8 ? 

You can still represent the characters from your oriental character
sets using UTF-8, but it takes three bytes per character to do so
(instead of two bytes with UTF-16 and most legacy encodings).

UTF-8 is a win for English text, since the ASCII characters are
represented with one byte.  For most scripts, however, UTF-8 takes up
more bytes per character than UTF-16.  It is well known the three
bytes per character range includes the CJK ideographs, but it also
includes Hangul, the South and Southeast Asian Scripts, and others too
numerous to mention here.

Whether UTF-8 or UTF-16 is better depends both on what scripts you
mainly use and on what your tools support (since neither UTF-8 support
nor UTF-16 support is universal among general-purpose programming
languages or editors or...).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lindsey at diac.com  Fri Nov 12 17:11:13 1999
From: lindsey at diac.com (William Lindsey)
Date: Mon Jun  7 17:16:53 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <m3n1sk29pp.fsf@biff.bitsko.slc.ut.us>
Message-ID: <Pine.LNX.4.10.9911130102040.29947-100000@cobra.diac.com>


Ken MacLeod writes:

>   {foo this is a foo, {subfoo this is subfoo.}
>    This is {subfoo{=bar with an attribute}}.}

Proposals for similar concrete syntaxes were discussed
during XML's development.  I'm satisfied with the result.

People interested in the idea of using S-Expressions
may be interested in an SGML markup language I defined 
a while back. The concrete syntax appears so close
to Scheme, that a document actually can be run by an R5RS
interpreter, yet is also valid SGML.

http://www.blnz.com/lml


Enjoy,

Bill





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



From lauren at sqwest.bc.ca  Fri Nov 12 17:48:59 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:16:53 2004
Subject: SML answers for SML problems
In-Reply-To: <001601bf2cfd$7cee4000$099918d1@docuverse1>
Message-ID: <199911121746.JAA24650@mail.sqwest.bc.ca>

On 12 Nov 99, at 3:02, Don Park wrote:

> One of the goals for SML should be:
> 
>     SML is what people think XML is.
> 
> By people, I mean the engineers understand the key concepts
> behind XML but have not yet been spoiled by the hairy details.
> SML should fit the mental model of XML people build when they
> first hear about XML.

Funnily enough, if you go back 3 years, and substitute "SGML" for 
"XML" and "XML" for "SML", you get the discussions many of us 
were having about why XML was an advantage over SGML... 
mostly, that XML was what most people thought SGML was, or 
should have been.

So SML is 20% of 20% of SGML? Hmmm, does 4% of SGML 
deliver 64% of the usefulness? 


Lauren

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 18:22:56 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:53 2004
Subject: SML and History
Message-ID: <3.0.32.19991112102341.014e0da0@pop.intergate.ca>

At 05:48 AM 11/11/99 -0800, Don Park wrote:
>Everyone,
>
>I have been thinking that there are applications out there that
>can benefit from using XML yet donot need all of its features.

There is some history there.  Shortly after the release of XML, some folks, 
including some very important folks in W3C and its members, who had been big 
supporters of XML, actually got around to reading the spec, and discovered to 
their horror that they had, instead of DPML (Don Park Markup Language), 
an XML which included entities, DTDs, PIs, and assorted other baggage.

As a result of that, the W3C created a Working Group called the "XML Syntax
Working Group" (now expired), co-chaired by me and Joel Nava, with a few 
deliverables, including some sort of simplified XML and also a "Canonical 
XML" format for use in conformance testing and digital signatures.  Last 
things first: Canonical XML still lives, has public Working Drafts, and 
quite likely some day be a W3C Recommendation.  Co-editors Bray/Clark/Tauber.

Simplified XML failed to happen because the WG totally failed to achieve
consensus on what it ought to be.  My memory is foggy but I seem to recall
that everyone agreed that references to external entities should be 
suppressed, but I can't bring to the front of my mind any one other thing 
that everyone agreed on.

Further complicating the picture was the lack of objective evidence that
a simplified-XML subset would actually be significantly cheaper in terms
of memory footprint or processing speed or implementation time.

Further complicating the picture was strenuous resistence by some, including
me, to any weakening of XML's internationalization capabilities.  
Restricting it to one encoding (probably UTF-8) would have had serious
cost to XML's acceptance in one part of the world or the other.  Furthermore,
since most real-world data is in EBCDIC or JIS or ISO-Latin, the net result
would have been moving the character conversion logic from the parser to
another piece of software with no net saving.

Further complicating picture was serious concern by some, again including
me, about "splitting XML".  Given the existence of a simplified XML, many
vendors would gleefully leap on board, support only that, announce to the
world that they supported XML, and throw any incoming document on the floor 
that happened to include lots of things that XML 1.0 said was legal.  
Speaking only for myself, this was the blood-in-the-water issue.

At the end of the day, I agree with Don Park that too much stuff made it
into XML 1.0 (although in the last months of the development of the spec,
we were kept busy full-time resisting the addition of more stuff).  However, 
looking back over the past couple of years, it seems that it came out 
just-barely-small-enough to hit the sweet spot.  Nobody is more conscious 
than me of the unnecessary extras in XML 1.0, but these acknowledged flaws 
seem not to be fatal nor even, in the big picture, all that serious.

For example, I'm in the late stages of building a big application with
XML plumbing that would get just fine with DPML (Don Park Markup Language).
Who cares?  I create the XML with a few printf() statements (for the
cognoscenti: ap_rprintf()), and pick up the nearest XML parser to read
it with.  The cost of having features I'm not using seems very moderate, 
and the benefit of merely having to specify "the interface is XML 1.0," 
without any fine print, seems quite high.

There is some valid concern with the growing height of the stack of 
other related recommendations that are being heaped on the back of XML 1.0.
Speaking only for myself, I surely don't have the mental bandwidth to be on 
top of XPath and XSLT and XSchema and XLink and DOM and the Infoset and so 
on all at once; I can't imagine that anyone except maybe James Clark does.
It's important that these things be built, insofar as possible, so you can 
pick and choose and just use the one or two you want without getting yourself
into complex dependencies.  So far, I think the specs have done a reasonably
good job of that.  Where they haven't, it should be treated as a bug.

 -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 18:40:59 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:16:53 2004
Subject: Why do we write standards?
In-Reply-To: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>
	(message from Bill dehOra on Fri, 12 Nov 1999 09:07:17 -0000)
References: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>
Message-ID: <199911121839.MAA02398@bruno.techno.com>

> From: Bill dehOra <Wdehora@cromwellmedia.co.uk>

> I worry about XML, when I see 'added extras' like metadata,
> namespaces, XSL, CSS, XLink crawling out of the woodwork. Not that
> the goal of these standards isn't desirable. But they serve to make
> XML complicated and difficult to implement.

Hear, hear.  

The problem isn't that, for example, there is an XML Namespaces
Recommendation.  As I see it, the problem is that many of these kinds
of things are being done with the idea that they are somehow going to
require support from all XML implementations, thus making XML a bigger
and bigger monolith, more and more self-contradictory and redundant,
and harder and harder to understand and implement in any given
situation.

For example, with the best of intentions, the XML InfoSet
Recommendation could regard XML itself as having non-optional
properties that *must* exhibit values when Namespaces are used.  But
it would be much better (more parsimonious, more modular, less obese)
to make support for such properties optional, so that, for example,
all XML implementations are not required to recognize colonized names
as namespace references.  The difference is all in whether we view
Namespaces as *an intrinsic aspect of XML* (bad), or whether we view
Namespaces as *a particular technique for using XML* (good).

Bill dehOra's note reminded me of some words that I heard on the
occasion of the death of a certain monolithic standard that died of
obesity:

  "In attempting to make the standard as useful as possible for every
  purpose, we made it so big and complex that nobody could use it for
  any purpose."

  "This standard absorbed all available resources, grew bigger and
  bigger, and provided no benefit to anyone.  This standard was a
  cancer, it had to die, and we're better off now that it's dead."

XML can be saved from obesity.  After all, SGML never succumbed.  Of
course, SGML has Charles Goldfarb to defend it against creeping scope.
And he does defend it very staunchly indeed, and maintaining that
defense has occasionally been costly.  

(I'm trying to think who defends XML from creeping scope.  I should
know the answer to that question, but I don't.)

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From niko at cmsplatform.com  Fri Nov 12 18:43:22 1999
From: niko at cmsplatform.com (Nik O)
Date: Mon Jun  7 17:16:53 2004
Subject: XML Schema and international Booleans
Message-ID: <012201bf2d3d$c4318d60$1a5e360a@tetondata.com>

Gregg Reynolds wrote:
>
>If we wanted to be really up-to-the-minute, we could follow
>the usage of logicians and use U+22A4 (DOWN TACK)
>and U+22A5 (DOWN TACK) as the canonical values [...]

Why not use U+22A8 (TRUE) and U+22AD (NOT TRUE)?  I don't know how
logicians/mathematicians use these, but presumably they are used enough that
the Unicode org described them.

There would be no confusion with the Roman letter "T", and
"pi(e)-on-the-side" is one of the seven true paths to happiness, que no?

Regards,
 Nik O, Teton Data Systems, Jackson, Wyo.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 18:52:42 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:53 2004
Subject: Good stuff on XHTML modularization
Message-ID: <3.0.32.19991112105323.01152e00@pop.intergate.ca>

I saw the posting included below on another mailing list where they worry
about XHTML.  It struck me as the best explanation of the XHTML 1.1
modularization thinking that I had run across and asked the author, Sebastian 
Schnitzenbaumer of Stack Overflow, a member of the HTML WG, why he didn't
post it on XML-DEV.  Turns out he'd found the flame content a little high
around here (he has a point) but asked me if I'd mind relaying it.  I 
don't.  

He asked me to point out that this is *not* a statement on behalf of the
HTML WG, and this is definitely work-in-progress, but I gather represents
some of the thinking going on over there. 

==============================================================

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

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

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

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

One might ask, why modularization in the first place? I guess this 
is similar here at the Web3D consortium, we have a lot of different 
implementors who address specialized domains and the times of 
"one size fits all" are over. It is desirable to allow innovation, and
allowing innovation means allowing variants. But how do you let 
others create variants in a safe way?

Here is the model the HTML WG is currently developing:

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

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

XHTML 1.0 introduces the XHTML namespace, without implying 
versioning (NS URI is now "http://www.w3.ort/1999/xhtml" BTW).

Modularization slices XHTML 1.0 into a dozen "modules". Think of 
a markup language as a cake. If you are sure that someone won't 
take the whole cake but only some slices, then it is better to define
"default cuts" instead of letting everyone randomly cut the thing into
pieces. If Vendor A says I'm using slices X, Y, Z and Vendor B 
says Y, Z, P, then Author C will now the Y and Z is the same in 
both Vendor A's and Vendor B's implementation.

Modularization of XHTML is the "module repository". In the module 
repository, there are more modules than a single version of XHTML 
can use, for instance, there are two forms module (HTML 3.2 forms 
and HTML 4.0 forms) and two tables modules, etc.

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

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

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

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

Vendor A thinks StandardML is nice, but rather than providing a 
strictly comforming StandardML implementation, Vendor A wishes 
to implement something different.

Subsets done by either Vendor A or Consortium:

Vendor A isn't capable of fully implementing StandardML. Vendor A 
creates a new StandardML "family member" by creating the 
specifc combination of just the 8 mandatory modules known as the 
Markup Language "StandardML-Basic". Since StandardML-Basic 
is a strict subset, it still belongs to the StandardML namespace.

Extended Subsets or Supersets done by Consortium only:

Consortium creates new modules, adds them to the module 
repository, creates a new specific combination of both old and new 
modules called StandardML 2.0. Consortium may either:

- hereby extend the StandardML namespace by the new modules
- introduce a wholy new namespace "StandardML 2.0", if the 
outcome is a completely new markup language where the names 
used in StandardML 1.0 are used in a complete different way in 
StandardML 2.0 (<p> suddenly meaning "parrot").

Extended Subsets or Supersets done by Vendor A:

Vendor A takes a set of module out the module repository, at least 
the 8 mandatory modules. Vendor A then creates one or many new 
modules after the guidelines set forth by Consortium. Vendor A 
now has five new StandardML-conforming modules. These five 
modules collectively define the MyML namespace being under 
control of Vendor A. The specific combination of modules (or family 
member) using both the 8 mandatory modules from Consortium 
plus the 5 new ones from Vendor A is called "StandardML-MyML".
The markup language StandardML-MyML has the StandardML 
namespace as the default namespace covering the StandardML 
modules, while the MyML modules in StandardML-MyML belong to 
the MyML namespace.

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

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

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

</body>
</html>

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

For those of you who have access to the W3C website, check:
http://www.w3.org/Markup/Group 
for the links to the latest versions of the specs.

Otherwise, please see the public drafts:

XHTML 1.1 - Module-based XHTML
http://www.w3.org/TR/xhtml11/ 

Modularization of XHTML
http://www.w3.org/TR/xhtml-modularization/ 

Building XHTML Modules
http://www.w3.org/TR/xhtml-building/ 


Regards,

Sebastian

---
Stack Overflow AG
Phone: +49-89-767363-70



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 12 19:20:03 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:16:53 2004
Subject: XML Schema and international Booleans
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16F7D@martinique>

> -----Original Message-----
> From: Nik O [mailto:niko@cmsplatform.com]
> Sent: Friday, November 12, 1999 12:42 PM
> 
> Gregg Reynolds wrote:
> >
> >If we wanted to be really up-to-the-minute, we could follow
> >the usage of logicians and use U+22A4 (DOWN TACK)
> >and U+22A5 (DOWN TACK) as the canonical values [...]
> 
> Why not use U+22A8 (TRUE) and U+22AD (NOT TRUE)?  I don't know how
> logicians/mathematicians use these, but presumably they are 
> used enough that
> the Unicode org described them.
> 

If they're accurately labeled, I'd say use 'em, but I somehow got the idea
those are used in writing proofs to express logical entailment (or whatever
the term is) or something like that, rather than truth.  I.e., I suspect
Unicode got the labels slightly wrong.  But I must also stress that I'm not
a logician, I only play one on the internet.  I'm quite fond of
non-sequiters, especially since my tennis shoes are in the wash.  I guess my
main objection to U+22A8 and U+22AD is they seem to define false in terms of
true, which seems to denigrate falseness, and is clearly insensitive to
liars.

> There would be no confusion with the Roman letter "T", and
> "pi(e)-on-the-side" is one of the seven true paths to 
> happiness, que no?
> 

Doesn't somebody have an international symbol for beer we could use for
'true'?

-gregg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Volkmann at AGEDWARDS.com  Fri Nov 12 19:52:02 1999
From: Mark.Volkmann at AGEDWARDS.com (Volkmann, Mark)
Date: Mon Jun  7 17:16:53 2004
Subject: default encoding
Message-ID: <5D176C6118FFD211B3A700902761F0F0FC446D@hqexchn8.agedwards.com>

If I start an XML document with
<?xml version="1.0"?>
what is the default encoding?
Is it just determined based on the first four bytes?

--
 __  __
/  \/  \        Object Computing, Inc.
\      / ark    (314)589-1617 pager
                (314)955-8123 A.G.Edwards
  \  / olkmann  (314)579-0066 OCI
   \/           volkmann@inlink.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 20:08:45 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:53 2004
Subject: default encoding
Message-ID: <3.0.32.19991112120824.01400a70@pop.intergate.ca>

At 01:50 PM 11/12/99 -0600, Volkmann, Mark wrote:
>If I start an XML document with
><?xml version="1.0"?>
>what is the default encoding?
>Is it just determined based on the first four bytes?

UTF-8 unless otherwise specified. -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 20:32:43 1999
From: grove at infotek.no (Geir Ove Grønmo)
Date: Mon Jun  7 17:16:53 2004
Subject: GPS - Groves and Property Sets for Python 0.20
Message-ID: <GROVE-823dubo3h0.fsf@pc-grove.infotek.no>


Hello,

I'm pleased to announce the second release of GPS - Groves and
Property Sets for Python. 

There has been a lot of changes in this release. The most important
being the support for grove managers and managed grove nodes, and a
grove walker module. See the changes.txt file in the distribution for
a complete list of changes.

Suggestions and bug reports should be sent to: grove@infotek.no

Geir O. Gr?nmo

--------------------------------------------------------------------------

Title: GPS - Groves and Property Sets for Python

Version: 0.20
Released: November 12th 1999

Author: Geir O. Gr?nmo, grove@infotek.no
License: GPL

Homepage: http://www.infotek.no/~grove/software/gps/index.html

- --
>>> What is GPS?

GPS is an implementation of the groves and property set concepts
defined in the HyTime and DSSSL standards. GPS is written in Python,
and should work* on any platform to which Python have been ported -
including the Java Platform.

There are two implementations in the current distribution, one
in-memory implemention and one that supports ZODB - the Zope Object
Database. Both groves, property sets and grove plans can be made
persistent by the ZODB implementation.

- --
>>> Features

 o Loading of property sets from documents conforming to the Property
   Set DTD, or any derived DTD [requires architectural processing].

 o Grove plans. Default grove plans is automatically created by
   wrapping a GrovePlan object around a property set. Inclusion and
   omitting of modules, classes and properties are fully supported.

 o Self-managed and managed grove node implementations, both generic
   classes for representing grove nodes.

 o Grove managers that manages a repository of managed grove nodes.

 o ZODB - Zope Object Database versions of all grove, grove manager,
   property set and grove plan classes, plus some ZODB utilities.

 o Module for building XML groves from SAX event streams. This module
   also contains a class for emitting SAX events by walking XML groves.

 o Grove walkers, allows for selective processing of groves.

 o Sample Property Sets

- --
>>> Requirements
   
  - Python 1.5.2 or newer [3]
  - An SGML/XML parser with a SAX driver
  - SAX 1.0 for Python [4]
  - xmlarch 0.25, optional unless architectural processing is needed [5]

- --
>>> References

[1] http://www.jpython.org/
[2] http://www.ornl.gov/sgml/SC34/
[3] http://www.python.org/
[4] http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxlib.html
[5] http://www.infotek.no/~grove/software/xmlarch/index.html
[6] http://www.infotek.no/~grove/software/gps/licence.html

* The ZODB implementation won't work in a Java environment, since ZODB
contains code written in C.

--------------------------------------------------------------------------

<P><A HREF="http://www.infotek.no/~grove/software/gps/index.html">GPS
- Groves and Property Sets for Python version 0.20</A> an
implementation of the groves and property set concepts defined in the
HyTime and DSSSL standards. (12-Nov-1999)

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



From psaintandre at corp.webb.net  Fri Nov 12 22:10:20 1999
From: psaintandre at corp.webb.net (Peter Saint-Andre)
Date: Mon Jun  7 17:16:53 2004
Subject: documenting schemas/DTDs
Message-ID: <8D96EDA0AC04D31197B400A0C96C1480811034@ossex1.ossinc.net>

Chapter 5 of the XML Schema working draft is a placeholder for
recommendations regarding the documenting of schemas, and the available
information on DDML and XSchema for DTDs seems somewhat out of date. What is
the status of documentation efforts for XML? I'd sure like to have at my
disposal an "XMLdoc" technology similar to Javadoc....

Peter

--
Peter Saint-Andre
Software Engineer
http://www.webb.net/
psaintandre@webb.net


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



From gkholman at CraneSoftwrights.com  Fri Nov 12 22:41:44 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:16:53 2004
Subject: external parsed entites (was: A unique ID question ?)
In-Reply-To: <Pine.LNX.4.10.9911111718060.10778-100000@cantor.clarkevans
 .com>
References: <4.2.0.58.19991111113026.00ae3c50@pop1.attglobal.net>
Message-ID: <4.2.0.58.19991112164320.00a76630@pop1.attglobal.net>

At 99/11/11 17:18 -0500, Clark C. Evans wrote:
>On Thu, 11 Nov 1999, G. Ken Holman wrote:
> > But I think that is beside the point.  Should tools be limiting the way I
> > work?  Hopefully not.  I want to work with small chunks and external 
> parsed
> > entities help me do that.
>
>Ken,
>
>I've always been afraid of external entities.
>Do you have some examples you can share?

Logically, my document model is made up of modules, one is used for each 
major topic.  Each module is made up of an optional intro, followed by 
lessons, followed by the optional exit.  Each of these breaks down into 
frames, and each frame is made of a set of panes and prose.

When assembled as slides for instructor-led training, each pane of a frame 
makes a separate slide (both HTML on-screen slides and print pages).

When assembled for web-based CBT (currently being set up with an Australian 
company), each frame makes a separate page and the individual panes merge.

When assembled as a prose book, the chapters and sections come from the 
modules and lessons and the content from the prose (with backup to the pane 
content during the process of writing the prose if there is no prose for a 
given frame).

Physically, I break down the source into separate external parsed entities 
for each module, and within each module for each lesson ... thus, I'm only 
focusing on one lesson at a time when actually doing my writing:

main.xml:

   <course>
     <intro>
     </intro>
     &module1;
     &module2;
   </course>

module1.xml:

   <module>
     <intro>
     </intro>
     &lesson1-1;
     &lesson1-2;
   </module>

module2.xml:
   <module>
     <intro>
     </intro>
     &lesson2-1;
     &lesson2-2;
   </module>

lesson1.xml:
   <lesson>
     <frame>
       <pane>
       </pane>
       <prose>
       </prose>
       <pane>
       </pane>
       <prose>
       </prose>
     </frame>
     <frame>
       <pane>
       </pane>
       <prose>
       </prose>
     </frame>
   </lesson>

Note that I do not name the entities with numbers, I label them with the 
concepts of the content ... I've just numbered them above to illustrate the 
physical hierarchy.

Prose content and pane content are authored side by each, as the production 
process winnows the undesired components for a given configuration.  This 
helps me ensure both forms of the content are in sync.

Concepts of applicability and effectivity are used to configure the 
material for either 45-minute, 90-minute, half-day, full-day lecture 
versions, two-day lecture or hands-on versions, or the book prose version 
*at a semantic level*.  This allows me to leverage the content at many 
different fora for different delivery lengths and host client 
needs.  Applicability can be used at either high (module) or low (phrase) 
levels of the document hierarchy.

The content configuration is *not* done by selectively including separate 
parsed entities, rather, the *entire* book (and *all* entities) is read in 
during a configuration/applicability XSLT transform that emits the 
effective result (based on applicability) that is then processed into 
slides or prose book format.

Host or publication detail configuration (title, language, logos, 
marginalia, ISBN, etc.) is accomplished via extensive use of external 
parameter entities and numerous marked sections.

The XSLT stylesheet components are also combined at the semantic level, not 
syntactic level, utilizing the xsl:include and xsl:import (xsl:import gives 
a *big* win when doing the print by importing already written logic for 
display).  I'm using XT for production and JADE for DSSSL/RTF/PDF publication.

I hope this helps.

.................. Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 22:58:50 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:16:54 2004
Subject: XML Schema and international Booleans
Message-ID: <33D189919E89D311814C00805F1991F7F4A85C@RED-MSG-08>

Several people have expressed dissatisfaction with the currently-proposed
representation of booleans in XML schemas datatypes. I second Rick Jeliffe's
suggestion that, if you have such disagreements, the most practical step you
can take is to give the W3C a well-thought-out alternative proposal, now.  

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



From DaviesA at logica.com  Fri Nov 12 23:28:00 1999
From: DaviesA at logica.com (Davies, Andrew)
Date: Mon Jun  7 17:16:54 2004
Subject: unsubscribe
Message-ID: <F19FD45DABBAD211922400A0C9663DDA6665CF@ritchie.us.logica.com>

unsubscribe

------------------------------------------
Andrew Davies
Senior Consultant
Logica Inc.
Financial Services Division
tel. +1 212 455 8230
email daviesa@logica.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 23:57:27 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:54 2004
Subject: SML and History
In-Reply-To: <3.0.32.19991112102341.014e0da0@pop.intergate.ca>
Message-ID: <001901bf2d69$f28b61a0$099918d1@docuverse1>

Tim,

>Simplified XML failed to happen because the WG totally failed 
>to achieve consensus on what it ought to be.  My memory is
>foggy but I seem to recall that everyone agreed that references
>to external entities should be suppressed, but I can't bring to
>the front of my mind any one other thing that everyone agreed on.

I consider this to be one of the two major stumbling block for SML
as well.  Just thinking about the discussion on whether to include
attribute or not gives me headaches.

>Further complicating picture was serious concern by some, 
>again including me, about "splitting XML".  Given the existence
>of a simplified XML, many vendors would gleefully leap on board,
>support only that, announce to the world that they supported XML,
>and throw any incoming document on the floor that happened to
>include lots of things that XML 1.0 said was legal.  Speaking only
>for myself, this was the blood-in-the-water issue.

This is the other major stumbling block.  Ignorant marketeers
reasoning "SML is XML so we are supporting XML!  Let's put that
on the box."  I have no answer for this sort of thing happenning
other than a firing squad.

Best,

Don Park    -   mailto:donpark@docuverse.com
Docuverse   -   http://www.docuverse.com

PS: I rather liked the name Don Park Markup Language <g>.

<dpml>
  <excited>Lets do this!  <jump>Lets do that!</jump></excited>
  <pissed>AAarrrrhhhhgg!</pissed>
  <persistent>But...  I still think...</persistent>
  <objective>Who is the bigger ass?  I am not sure.</objective>
  <funny>Len, are you a bot?</funny>
</dpml>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 23:57:26 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:54 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <14380.11614.10000.669791@menteith.com>
Message-ID: <001801bf2d69$f1ba5600$099918d1@docuverse1>

>You can still represent the characters from your oriental character
>sets using UTF-8, but it takes three bytes per character to do so
>(instead of two bytes with UTF-16 and most legacy encodings).

Right.  This means that SML is not a good choice for 'documents' nor
encoding data with lots of foreign characters.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 12 23:57:19 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:54 2004
Subject: SML answers for SML problems
In-Reply-To: <199911121746.JAA24650@mail.sqwest.bc.ca>
Message-ID: <001101bf2d69$eddd9100$099918d1@docuverse1>

>Funnily enough, if you go back 3 years, and substitute "SGML" for 
>"XML" and "XML" for "SML", you get the discussions many of us 
>were having about why XML was an advantage over SGML... 
>mostly, that XML was what most people thought SGML was, or 
>should have been.
>
>So SML is 20% of 20% of SGML? Hmmm, does 4% of SGML 
>deliver 64% of the usefulness?

If 0% of SGML is TEXT then 4% seems useful enough. <g> Frankly,
I am still not sure if SML has enough momentum to fly.  I am
just talking the talk and walking the walk to see if where it
leads.  Ideas tend to have a mind of its own.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 00:08:54 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:54 2004
Subject: Good stuff on XHTML modularization
In-Reply-To: <3.0.32.19991112105323.01152e00@pop.intergate.ca>
Message-ID: <001a01bf2d6b$7d452fa0$099918d1@docuverse1>

Sebastian Schnitzenbaumer wrote:
>XHTML 1.0 introduces the XHTML namespace, without implying 
>versioning (NS URI is now "http://www.w3.ort/1999/xhtml" BTW).

I am for calling it the X-MAS spec <g>
Rest of the message is great as well and makes a fun read.

Thanks for forwarding it, Tim.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Sat Nov 13 00:38:47 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:16:54 2004
Subject: XML Schema and international Booleans
Message-ID: <199911121938890.SM01340@Unknown.>

Re: English-only boolean values

> The best practical steps you should take are
>     1) come up with a little complaint, an alternative proposal and
> justification
>     2)post this to the comment mailing list at W3C
>     3) also, notify the w3c i18n WG that you think the approach is
> wrong.
> Your comment might be particularly appropriate at this time.
> 
> The other thing to consider is that XMl Schemas 1.0 is already looking
> late: I would prefer they leave out value renaming until XML Schemas 2.

Okay, perhaps this is a very stupid question, but here goes: Who cares if the schema 
spec meets a given deadline?  Exactly what is meant by it being "late"?

Think about this for a minute - would you rather have a product (or spec) that's ready 
tomorrow but still needs work, or a product that's going to be delayed a bit, but has been 
fixed?  Not to sound snippy, but as a user/developer, I absolutely abhor the "it's broken, 
but we'll fix it in the service pack" approach - I want to be able to use the product (or 
spec) when it's released...and if Getting It Right means delaying the release, I'm all for it.

If the logic behind this lateness involves vendors who are eagerly waiting to release 
software, then it becomes exponentially MORE important to fix it in the original spec - 
because a few years down the line, that software is still going to be around and 
developers are going to have to work around its limitations.  In the long view, which 
would you rather have - a momentary delay of the initial implementation, or an eternity 
of conforming to a spec that nobody favors because there are still tools out there that 
don't understand anything better?

Software doesn't go away.  I can go through logs from earlier this year and point out 
visitors to my site who use IE 2.1 (AOL edition) and Netscape 2.01 - which means that I 
still have to find some way to accomodate them.  In the case of NN2, that means 
deliberately breaking compliance with the spec to get around a browser bug.  I still see 
people using Windows 3.x - a piece of software fully six years old.  It's easy to look at 
those version numbers and shudder at how primitive that software was - but it's still out 
there, and still in use, so it still has to be accomodated if you care about accessibility.

Five years from now, we'll look back on current tools with similarly jaundiced eyes, and 
people like me will resent the "patch it later" attitude precisely because every time 
someone says that, the market fragments a little bit more (with no good reason!) - and 
that just means more work for those of us in the field.  Humbug, I say, humbug.  Get It 
Right - even if that means the timetable has to go out the window.  We've waited this 
long; a little longer won't kill us.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 03:10:51 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:16:54 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <001801bf2d69$f1ba5600$099918d1@docuverse1>
References: <14380.11614.10000.669791@menteith.com>
	<001801bf2d69$f1ba5600$099918d1@docuverse1>
Message-ID: <14380.50928.800000.413803@menteith.com>

At 12 Nov 1999 15:35 -0800, Don Park wrote:
 > >You can still represent the characters from your oriental character
 > >sets using UTF-8, but it takes three bytes per character to do so
 > >(instead of two bytes with UTF-16 and most legacy encodings).
 > 
 > Right.  This means that SML is not a good choice for 'documents' nor
 > encoding data with lots of foreign characters.

Foreign to whom?  The World Wide Web?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From anandram at wipsys.soft.net  Sat Nov 13 04:26:34 1999
From: anandram at wipsys.soft.net (Anand Raman)
Date: Mon Jun  7 17:16:55 2004
Subject: XSL patterns give me a node--how can I find it's position?
References: <4139ED560536D3118F100008C7F36E451A8D38@HQMAIL>
Message-ID: <382CE6D7.F389673D@wipsys.soft.net>

Hi ben
Can u tell me how you use the XQL pattern books/book[@bnum = 13241] to
search ur xml files for elements , from a lay man point of view.
I know a little of XQL , XML and the syntax for forming notations .
However i could never figure out how to implement them in IE5.
Thanx a lot for ur time
Bye
Anand Raman

Ben Berck wrote:

> I am using the (IE5) XML DOM to search for a particular node.
>
> I use a pattern like this:
> books/book[@bnum = 13241]
>
> It correctly finds a match.  Now my question is, how do I determine
> the position of the found book in "books"?  bnum is not in sequential,
> nor is it in order.  I need to know which book it is within the
> books.childNodes NodeList.
>
> Do I have to step through every element of books.childNodes and match
> it myself?
>
> Thanks in advance,
> Ben Berck
> ESPS, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991113/d7ca9352/attachment.htm
From donpark at docuverse.com  Sat Nov 13 05:22:04 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:55 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <14380.50928.800000.413803@menteith.com>
Message-ID: <000401bf2d97$47cb9860$099918d1@docuverse1>

> > Right.  This means that SML is not a good choice for 'documents' nor
> > encoding data with lots of foreign characters.
>
>Foreign to whom?  The World Wide Web?

By foreign, I meant characters that must be escaped under UTF-8.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 06:03:14 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:55 2004
Subject: Why do we write standards?
Message-ID: <006001bf2da0$26350750$41f96d8c@NT.JELLIFFE.COM.AU>


From: Joshua E. Smith <jesmith@kaon.com>

>  (If W3C required just one working implementation it would be
>a quantum improvement of the process.  It's a great way to fight the
>natural tendency for bloat.)

Which is why the enabling framework for "standards" is more important
than the standards:  TCP/IP is more important than HTTP,  MIME types are
more important than HTML or XML, the maligned stylesheet PI is more
important than CSS or XSL, why namespace URIs are (potentially) more
important than schemas, etc.  At every lower level, there needs to be
mechanisms in place to allow plurality and experimentation at the
next-higher level.

If we look at XML, we can see a couple of places where this mechanism is
missing, and it will bite us:

* We now have four kinds of XML: WF, Canonicalized, Valid with DTD, XML
with namspaces: actually, since they are not mutually exclusive, maybe
that gives us 8 kinds of XML. But there is no standardized way for a
document to announce which of these forms it is (I suppose the
standalone declaration does something like this).   The early drafts of
the Schema spec introduced "nearly well-formed", and the SML idea
introduces another variant.

* It has seemed like there will be no standardized way to invoke schemas
other than DTDs or (future) XML schemas. Without such a thing, there is
little way for experimental implementations or even for the market to
decide between alternatives. Plurality is not bad for us: even in the
area of schemas.

There are some people for whom standardization means homogenization: in
each area, we should only have one technology.  There are others for
whom standardization means that there should be at least one
high-quality choice.  I subscribe to the latter, and to the view that
"enabling" standards are more important than "constraining" standards.

The W3C should set a policy that for every new domain they work in, in
good time before the release of a specification, enabling mechanisms
which allow plurality.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 06:13:15 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:16:55 2004
Subject: Good stuff on XHTML modularization
References: <3.0.32.19991112105323.01152e00@pop.intergate.ca>
Message-ID: <382D0054.34A6@hiwaay.net>

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

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

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

len

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


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

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

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

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

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

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

One might ask, why modularization in the first place? 

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

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

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

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

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

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

Len:  Why not?

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

Len:  Thank you.

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

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

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

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

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

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

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

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

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

Len: Yep.  he way to go..

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

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

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

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

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

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

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

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

</body>
</html>

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

Len: That is very cool.  

Regards, Sebastian

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

Regards, Len


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 06:58:28 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:55 2004
Subject: XML and SML
Message-ID: <006101bf2da7$ceb797b0$41f96d8c@NT.JELLIFFE.COM.AU>


From: Don Park <donpark@docuverse.com>

>I don't think the SML discussion is taking attention away
>from XML Schema discussions.  Why all the hostility, Rick?

I apologize to Don Park: there was no intention to be discourteous.

SML is a well-trodden path.

I first put out a grammar on comp.text.sgml for a simplified SGML
sometime about 1994 which I recall (I don't want to embarrass myself by
reading it) was pretty similar to what Don is suggesting, probably
SMLwith simple DTDs.  And there were several other, better efforts
around at a similar time.

At the time, Charles Goldfarb contacted me over it, and he gently
pointed out that however much SGML needed simplificiation or revision,
it had to come from credible grassroots demand and work, respecting the
generic markup principles behind SGML. In the fullness of time, that
came about through Jon Bosak and W3C, and everyone knows that the ISO
working group welcomed it (indeed, XML is incorporated into ISO 8879
through Annex L).

And, as for whether SML is a distraction from XML schemas, how many
postings have there been on XML-DEV about the structure drafts?  There
have been a couple of good ones about the datatypes, but not on the
structures, that I recall.  I predict that the moment that the XML
Schema becomes a recommendation, this mailing list will bustle with
well-reasoned calls for  simplified XML Schema--alas too late.

> Is And Borenstein's markup language XML?
> SML is and I believe it makes a difference.

The spec for text/enriched can be found at
        ftp://ftp.isi.edu/in-notes/rfc1563.txt
It has well-formed tags, a handful of pre-defined elements, the notional
top-level element must be omitted, and the notional paragraphs start tag
is (if we treat it as SGML) shortreffed to a blank line. If Don wants to
persue SML to standards-level, then one strategy could be to integrate
it with text/enriched: you could upgrade that so that if the
text/enriched document starts with a start-tag or comment, then it uses
the SGML rules other wise it uses the current text/enriched rules.

Another approach you could take for SML is to integrate it with a
short-tag system.
I have two small C utilities at http://www.sinica.edu.tw/~ricko/src/
that may be of interest.  The first short-tag-compress.c    compresses
an XML file using shorttag ommission.  The file short-tag-uncompress.c
uncompresses the file. (I wrote them to claims about verify XML's
behaviour w.r.t. deflate compression.) There is the  kernel of a very
simple XML in them it. (B.t.w., my results were that probably it would
be useful to use shorttag ommission on an XML document because even
though there was only a small effect when combined with compression, the
result was that more information would make it into the vital first
packet-group; the first group is important because it may contain link
in headers: the earlier these resources can be requested, the better the
perceived performance to the user. And, in any case, the code is so
trivial that even a 1% decrease in filesize might be enough to justify
it.)


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 07:39:37 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:55 2004
Subject: XML and SML
In-Reply-To: <006101bf2da7$ceb797b0$41f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000001bf2daa$819cf260$099918d1@docuverse1>

Rick,

>I apologize to Don Park: there was no intention to be discourteous.

No offense taken.  I was just trying to see whether I was being
abnoxious unintentionally.  I tend to do that often <g>.

>And, as for whether SML is a distraction from XML schemas, how many
>postings have there been on XML-DEV about the structure drafts?  There
>have been a couple of good ones about the datatypes, but not on the
>structures, that I recall.  I predict that the moment that the XML
>Schema becomes a recommendation, this mailing list will bustle with
>well-reasoned calls for  simplified XML Schema--alas too late.

I think there has not been much discussion over XML schema
because not many of us have read it throughly yet.  I agree that
the XML Schema spec needs more discussion and now seems like
the best time to do it.  Would you mind if I propose Simple XML
Schema (SXS)?  Just kidding (for now ;-).  Frankly, I am starting
to get dizzy with all the standards coming out and I am trying to
be more frugal with where I spend my time.

BTW, your Schematron stuff is great.  I thought Dave Raggett's
Assertion Grammar idea was cool but Schematron takes an interest
approach to achieve the same.  It makes me wonder why more people
are not paying more attention to it.  Discussion of Schematron
should make a very interesting thread.

Best,

Don Park    -   mailto:donpark@docuverse.com
Docuverse   -   http://www.docuverse.com

PS: I'll take a look at your short-tag system.  Thanks for the tips.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 11:03:30 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:16:55 2004
Subject: SML answers for SML problems
In-Reply-To: <001101bf2d69$eddd9100$099918d1@docuverse1>
References: <199911121746.JAA24650@mail.sqwest.bc.ca>
Message-ID: <3.0.6.32.19991113104630.009c3e60@gpo.iol.ie>

[Don Park]
>
>If 0% of SGML is TEXT then 4% seems useful enough. <g> Frankly,
>I am still not sure if SML has enough momentum to fly.  I am
>just talking the talk and walking the walk to see if where it
>leads.  Ideas tend to have a mind of its own.
>

Unfortunately, 0% of SGML is completely incompatible
with 0.1% of SGML. Same goes for XML.

What I mean is that plan text is not a subset
of SGML or XML. If XML is the new ASCII wouldn't
it be great if it was backwardly compatible with
the existing ASCII?

To be concrete. I think it makes a lot of sense
to allow a plain text document to parse and
emerge at the far end of an XML processor
as a single xml:text node consisting
of PCDATA.

>From a software development perspective this
appeals to be. I make text processing tools
such as, say, XML-aware search tools, yet
know that I can use em to process plain
text without any code changes.

regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 11:55:08 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:55 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: "Don Park"'s message of "Fri, 12 Nov 1999 15:35:59 -0800"
References: <001801bf2d69$f1ba5600$099918d1@docuverse1>
Message-ID: <m31z9uhajt.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> Right.  This means that SML is not a good choice for 'documents' nor
> encoding data with lots of foreign characters.

Like, say, a database with the names of subscribers to a Chinese
e-mag, or a collection of information about Arabic movies.  

Right now, it happens that a few large English-speaking former British
colonies (U.S., Canada, Australia, New Zealand) and Western Europe
make up a majority of the computer-using world, but since we make up a
small minority of the world in general, I expect that things will
change rapidly -- data from Turkey or Saudi Arabia or Japan or Korea
can have exactly the same problem as a document.

Actually, in the end I found that supporting UTF-16/UCS-2 as well as
UTF-8 wasn't that hard in AElfred (again, just a few lines of code,
and I didn't use the Java 1.1 library stuff).  The hard part about
Unicode is that there's such a wide range of characters allowed and
not allowed in each context, and XML 1.0 *requires* parsers to report
all of those errors.  That's a problem with UTF-8 as well as UTF-16.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 11:58:40 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:55 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: "Don Park"'s message of "Fri, 12 Nov 1999 21:21:45 -0800"
References: <000401bf2d97$47cb9860$099918d1@docuverse1>
Message-ID: <m3yac2fvth.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> > > Right.  This means that SML is not a good choice for 'documents' nor
> > > encoding data with lots of foreign characters.
> >
> >Foreign to whom?  The World Wide Web?
> 
> By foreign, I meant characters that must be escaped under UTF-8.

Oops!  That also includes characters 128-255, which means all accented
Western European characters (though they consume only two octets each
in UTF-8).


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 12:10:47 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:55 2004
Subject: Many dialects of XML?
In-Reply-To: "Rick Jelliffe"'s message of "Sat, 13 Nov 1999 14:26:54 +0800"
References: <006001bf2da0$26350750$41f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <m3vh76fv9a.fsf@localhost.localdomain>

"Rick Jelliffe" <ricko@allette.com.au> writes:

> * We now have four kinds of XML: WF, Canonicalized, Valid with DTD, XML
> with namspaces: actually, since they are not mutually exclusive, maybe
> that gives us 8 kinds of XML. 

As I understood it, Canonicalized XML was really defining a mask for
comparing XML documents -- it's not a separate dialect that processors 
are free to support or ignore, so it doesn't belong in the list.

All processors must support well-formed XML, so that's a given for any
possible variant.  Still, that leaves the following four combinations:

  Well-formed
  Well-formed + valid
  Well-formed + Namespaces
  Well-formed + valid + Namespaces

Compare this list to

  WebSGML
  SGML
  WebSGML + Architectural Forms
  SGML + Architectural Forms

After all, while many XML-related specs (i.e.Schemas and XSL) require
Namespaces, many SGML-related specs (i.e. HyTime and DSSSL) require
Architectural Forms.

Actually, I'm cheating a little in SGML's favour right now, since the
SGML declaration creates a potentially infinite number of SGML
variants that any SGML parser is free to support or reject (outside
the reference concrete syntax): in SGML you can end up with a
processor that allows UTF-16, 4096-character PIs and 8-character
names, and another that allows only US-ASCII, 128-character PIs, and
1024-character names.

> But there is no standardized way for a document to announce which of
> these forms it is (I suppose the standalone declaration does
> something like this).  

Yes, the SGML declaration helps that situation a little, but only to
the extent that you can find out *why* two SGML tools refuse to
interoperate.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Sat Nov 13 14:28:03 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:55 2004
Subject: Feeler for SML (Simple Markup Language)
References: <001801bf2d69$f1ba5600$099918d1@docuverse1>
Message-ID: <00a301bf2de2$9a902520$421e12d1@PTGRESTON>


----- Original Message -----
From: Don Park <donpark@docuverse.com>
To: <xml-dev@ic.ac.uk>
Sent: Friday, November 12, 1999 6:35 PM
Subject: RE: Feeler for SML (Simple Markup Language)


> Right.  This means that SML is not a good choice for 'documents' nor
> encoding data with lots of foreign characters.

The UTF-8 restriction is the only one in your original list that really
worries me. There will be a lot of "data" transactions going around the
world with "foreign" (i.e. non-Western) names and descriptions in them.  It
would seem that there's an argument to be made for putting support for
UTF-16 (at a minimum) in the parser rather than force the applications to do
the UTF-8 encodings ...




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 14:39:12 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:55 2004
Subject: SML answers for SML problems
In-Reply-To: <3.0.6.32.19991113104630.009c3e60@gpo.iol.ie>
Message-ID: <000601bf2de5$2226ebc0$099918d1@docuverse1>

>To be concrete. I think it makes a lot of sense
>to allow a plain text document to parse and
>emerge at the far end of an XML processor
>as a single xml:text node consisting
>of PCDATA.

Interesting idea.  Only thing preventing that
is the root element rule which irks me sometimes.
Something like schematron could reduce the need
for the root element rule but I think we are stuck
with it for now.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 15:13:39 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:55 2004
Subject: APIs vs Markup
In-Reply-To: "Don Park"'s message of "Sat, 13 Nov 1999 06:36:44 -0800"
References: <000601bf2de5$2226ebc0$099918d1@docuverse1>
Message-ID: <m3puxefmsj.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> >To be concrete. I think it makes a lot of sense
> >to allow a plain text document to parse and
> >emerge at the far end of an XML processor
> >as a single xml:text node consisting
> >of PCDATA.
> 
> Interesting idea.  Only thing preventing that
> is the root element rule which irks me sometimes.
> Something like schematron could reduce the need
> for the root element rule but I think we are stuck
> with it for now.

Hmm ... it sound like what you're looking for is a common API, not a
common markup language.  There's no reason that someone couldn't write
a SAX driver that took

  Hello, world!

and reported

  startDocument()
  startElement("__dummy")
  characters("Hello, world!")
  endElement("__dummy")
  endDocument()

Ditto for a DOM builder.  You could do the same for LaTeX, NROFF, RTF,
comma-delimited fields, Excel spreadsheets, or whatever turns your
crank -- we're talking about APIs, not XML itself (which is simply an
external representation language).

As I've suggested often, there's a many-to-many relationship between
APIs and markup languages.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rja at arpsolutions.demon.co.uk  Sat Nov 13 15:48:05 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:16:56 2004
Subject: Feeler for SML (Simple Markup Language)
References: <001801bf2d69$f1ba5600$099918d1@docuverse1> <00a301bf2de2$9a902520$421e12d1@PTGRESTON>
Message-ID: <00be01bf2dee$4d1b3bc0$4a5eedc1@arp01>

But UTF-8 can support "foreign" characters so I dont see the argument for
having UTF-16 too.  Also, generally speaking UTF-8 encoding results in
smaller output for most cases.

Regards,

Richard A.
http://www.vivid-creations.com
http://www.iDevResource.com


MSXML/Windows developers mailing list -
http://www.onelist.com/community/dev-xml
Join now by sending a blank email to dev-xml-subscribe@onelist.com

----- Original Message -----
From: Michael Champion <Mike.Champion@softwareag-usa.com>
To: <xml-dev@ic.ac.uk>
Sent: Saturday, November 13, 1999 2:23 PM
Subject: Re: Feeler for SML (Simple Markup Language)


>
> ----- Original Message -----
> From: Don Park <donpark@docuverse.com>
> To: <xml-dev@ic.ac.uk>
> Sent: Friday, November 12, 1999 6:35 PM
> Subject: RE: Feeler for SML (Simple Markup Language)
>
>
> > Right.  This means that SML is not a good choice for 'documents' nor
> > encoding data with lots of foreign characters.
>
> The UTF-8 restriction is the only one in your original list that really
> worries me. There will be a lot of "data" transactions going around the
> world with "foreign" (i.e. non-Western) names and descriptions in them.
It
> would seem that there's an argument to be made for putting support for
> UTF-16 (at a minimum) in the parser rather than force the applications to
do
> the UTF-8 encodings ...
>
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 15:59:01 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:56 2004
Subject: APIs vs Markup
In-Reply-To: <m3puxefmsj.fsf@localhost.localdomain>
Message-ID: <000001bf2df0$4822bba0$099918d1@docuverse1>

>Hmm ... it sound like what you're looking for is a common API, not a
>common markup language.  There's no reason that someone couldn't write
>a SAX driver that took

True enough except there is a genuine problem of using XML to encode
data with no obvious root element.  For example, log data tends to
just accumulate and one has to use XML hacks to make the data meet
the root element constraint.  Best one can do is use the data as
well-formed external parsed entity.  I am not really obsessed about
this but it is somewhat annoying.

As far as APIs are concerned, I feel that APIs should pay more
attention to XML fragments handling.  Some parsers will parse
only XML documents.  Even SAX API's startDocument/endDocument
tend to make people think in terms of XML documents rather than
arbituary XML fragments.  Many people write SAX filters that expects
startDocument/startElement/.../endElement/endDocument sequence when
there is no real reason to.  I, for one, had some filters that
initialized on startDocument or first startElement which leaves
the filter in odd state when XML fragments are being parsed.

I am not really criticizing anyone here since I forgot to bring
this up when we were designing SAX (that reminds me, when will the
work on SAX 2 stuff be resumed?).  Lets just think about XML
fragments more when designing APIs from now on.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 16:07:07 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:56 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <00a301bf2de2$9a902520$421e12d1@PTGRESTON>
Message-ID: <000101bf2df1$6a4a84a0$099918d1@docuverse1>

>The UTF-8 restriction is the only one in your original list that really
>worries me. There will be a lot of "data" transactions going around the
>world with "foreign" (i.e. non-Western) names and descriptions 
>in them.  It would seem that there's an argument to be made for putting
>support for UTF-16 (at a minimum) in the parser rather than force the 
>applications to do the UTF-8 encodings ...

Heh.  Looks like we are already running into the consensus problem
the XML Syntax Working Group ran into while working on Simplified XML.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kragen at pobox.com  Sat Nov 13 17:04:49 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:16:56 2004
Subject: UTF-8 space efficiency
Message-ID: <Pine.GSO.4.10.9911131126560.25845-100000@kirk.dnaco.net>

UTF-8 requires:
- 1 byte each for the ASCII characters (U+0000 to U+007F), known as the
  "Basic Latin" block in Unicode.  This is better than UTF-16, and no
  worse than ASCII.
- 2 bytes each for characters from U+0080 to U+07FF.  This includes Latin-1,
  Latin Extended-A, Latin Extended-B, the IPA extensions, spacing
  modifier letters, combining diacritical marks, Greek, Cyrillic,
  Armenian, Hebrew, and Arabic.  This is no worse than UTF-16.
- 3 bytes each for U+0800 to U+FFFF.  This is worse than UTF-16, and it covers
  the vast majority of Unicode characters in use today.
- 4 bytes each for U+10000 to U+10FFFF.  This is no worse than UTF-16,
  and it potentially covers many more characters than in all the
  previous ranges put together, but it is currently nearly unused.  In
  the future, it is likely to be used only for extremely unusual
  scripts, such as Sumerian cuneiform, the Tengwar of Feanor, Egyptian
  hieroglyphics, hieratic, and demotic.  So I doubt this will be of
  much import to many people.

UTF-8 has some other advantages over UTF-16.  It has no byte-order
ambiguity, and for many purposes -- such as string-searching -- it can
be treated as simply a string of bytes.  And it's "filesystem-safe",
which means you can use it in filenames without modifying the
filesystem to be Unicode-aware.

>From my provincial American point of view, it looks like a space win,
too -- most of my text is ASCII anyway.  Obviously if I were mostly
using one of the numerous scripts in the UTF-8-disadvantaged area, I
might feel differently.

But to tell the truth, most of the space on my disk and bandwidth on my
modem isn't consumed by text, anyway.  A 50% increase in the size of
all that text wouldn't bother me much.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jjc at jclark.com  Sat Nov 13 18:09:10 1999
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:16:56 2004
Subject: default encoding
References: <3.0.32.19991112120824.01400a70@pop.intergate.ca>
Message-ID: <382CB37A.A922C3D4@jclark.com>

Tim Bray wrote:
> 
> At 01:50 PM 11/12/99 -0600, Volkmann, Mark wrote:
> >If I start an XML document with
> ><?xml version="1.0"?>
> >what is the default encoding?
> >Is it just determined based on the first four bytes?
> 
> UTF-8 unless otherwise specified. -T.

Or unless the first two bytes are a byte order mark, in which case it is
UTF-16.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From pandeng at telepath.com  Sat Nov 13 18:23:51 1999
From: pandeng at telepath.com (Steve Schafer)
Date: Mon Jun  7 17:16:56 2004
Subject: UTF-8 space efficiency
In-Reply-To: <Pine.GSO.4.10.9911131126560.25845-100000@kirk.dnaco.net>
References: <Pine.GSO.4.10.9911131126560.25845-100000@kirk.dnaco.net>
Message-ID: <383cab57.170516517@90.0.0.40>

On Sat, 13 Nov 1999 12:05:17 -0500 (EST), you wrote:

>And it's "filesystem-safe", which means you can use it in filenames
>without modifying the filesystem to be Unicode-aware.

That's not necessarily true. UTF-8 uses octets having values in the
range of 0x00 through 0xF4. Those greater than 0x7F can cause problems
with some file systems.

-Steve Schafer


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 19:13:22 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:16:56 2004
Subject: UTF-8 or ? for SML (was: Re: Feeler for SML (Simple Markup Language))
In-Reply-To: <00be01bf2dee$4d1b3bc0$4a5eedc1@arp01>
References: <001801bf2d69$f1ba5600$099918d1@docuverse1>
	<00a301bf2de2$9a902520$421e12d1@PTGRESTON>
	<00be01bf2dee$4d1b3bc0$4a5eedc1@arp01>
Message-ID: <14381.43469.540000.334071@menteith.com>

At 13 Nov 1999 15:46 -0000, Richard Anderson wrote:
 > But UTF-8 can support "foreign" characters so I dont see the argument for
 > having UTF-16 too.  Also, generally speaking UTF-8 encoding results in
 > smaller output for most cases.

Different people have different ideas of what constitutes "foreign".

For the majority of the characters in the Unicode Standard, UTF-8 uses
three bytes per character.  However, for the US-ASCII characters, it
uses only one byte per character.

For all characters in the Unicode Standard, UTF-16 uses two bytes per
character.

Whether a given file is less bytes as UTF-8 or UTF-16 is largely a
function of the proportion of unaccented Latin characters in the file.

Moreover, most legacy encodings for a single script use one byte per
character, although Chinese, Japanese, and Korean encodings use two or
more bytes per character.  UTF-8, therefore, isn't as efficient as the
legacy encodings of most scripts.  (Its advantage is that it can
represent more scripts than any legacy encoding.)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 19:40:03 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:56 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <3.0.32.19991113113706.01335d90@pop.intergate.ca>

At 03:46 PM 11/13/99 -0000, Richard Anderson wrote:
>But UTF-8 can support "foreign" characters so I dont see the argument for
>having UTF-16 too.  Also, generally speaking UTF-8 encoding results in
>smaller output for most cases.

The UTF-*'s are logically equivalent to most users, in that they share
the property that almost no real-world data objects are encoded in either.
One of the nice things about XML is that it allows you to store & transmit
your objects in any well-known encoding as long as you declare it.  I'm
delighted to observe that most of the real-world XML processors out there
effortlessly deal with various ISO-Latins and JIS and so on. -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 19:39:49 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:56 2004
Subject: SML answers for SML problems
Message-ID: <3.0.32.19991113113504.01335100@pop.intergate.ca>

At 06:36 AM 11/13/99 -0800, Don Park wrote:
>Interesting idea.  Only thing preventing that
>is the root element rule which irks me sometimes.
>Something like schematron could reduce the need
>for the root element rule but I think we are stuck
>with it for now.

Argh!  Heresy.  The single root element is one of the Good Things about
XML.  It means that you know unambiguously when an information unit has
ended in a way that's decoupled from the closure (or not) of the socket
by the programmer at the other end.  -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 19:39:46 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:56 2004
Subject: APIs vs Markup
Message-ID: <3.0.32.19991113113844.014a5310@pop.intergate.ca>

At 08:00 AM 11/13/99 -0800, Don Park wrote:
>True enough except there is a genuine problem of using XML to encode
>data with no obvious root element.  For example, log data tends to
>just accumulate and one has to use XML hacks to make the data meet
>the root element constraint.  Best one can do is use the data as
>well-formed external parsed entity.  I am not really obsessed about
>this but it is somewhat annoying.

For things like log files, just treat 'em as a succession of small
XML documents.  Is this a problem? -T.

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



From kragen at pobox.com  Sat Nov 13 21:14:17 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:16:56 2004
Subject: UTF-8 space efficiency
Message-ID: <Pine.GSO.4.10.9911131612100.5100-100000@kirk.dnaco.net>

Steve Schafer wrote:
> On Sat, 13 Nov 1999 12:05:17 -0500 (EST), you wrote:
> 
> >And it's "filesystem-safe", which means you can use it in filenames
> >without modifying the filesystem to be Unicode-aware.
> 
> That's not necessarily true. UTF-8 uses octets having values in the
> range of 0x00 through 0xF4. Those greater than 0x7F can cause problems
> with some file systems.

I believe you.  Do you know which filesystems they are?  Unix in
general is pretty charset-agnostic, except for reserving 0x00 and 0x2F
as pathname terminator and pathname separator.

IIRC, this was the major reason the Bell Labs guys invented UTF-8 -- so
the Plan9 filesystem could be dumb.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kragen at pobox.com  Sat Nov 13 21:19:17 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:16:56 2004
Subject: SML answers for SML problems
Message-ID: <Pine.GSO.4.10.9911131616450.5287-100000@kirk.dnaco.net>

Tim Bray writes:
> Argh!  Heresy.  The single root element is one of the Good Things about
> XML.  It means that you know unambiguously when an information unit has
> ended in a way that's decoupled from the closure (or not) of the socket
> by the programmer at the other end.  -T.

But you can have comments and PIs after the end of the root element.
So the single root element doesn't really solve this problem.

One protocol I remember reading about uses ]]>]]> to separate XML
documents, since that's a sequence that can't occur inside a legal XML
document.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 21:19:29 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:56 2004
Subject: APIs vs Markup
In-Reply-To: <3.0.32.19991113113844.014a5310@pop.intergate.ca>
Message-ID: <000001bf2e1d$09d449e0$099918d1@docuverse1>

Tim Bray wrote:
>For things like log files, just treat 'em as a succession of small
>XML documents.  Is this a problem? -T.

Neat.  Your idea seems to go hand-in-hand with your other message
about root element being a transport-independent device for knowing
when a document ends.  What about the miscelleneous stuff (production
#25) though?

Also it gets a little complicated when log entries have to reference
other log entries (for composite events or chain of events).  If each
log entries are midget XML documents, references between log entries
must be inter-document references.

I also wonder how many of the XML parsers out there will work with this
'succession of small XML documents' as is.  The SAX API should work
with it as long as people do not assume that startDocument/endDocument
methods are invoked exactly once per Parser.parse call.

Hmm.  Perhaps its time for the "Safe SAX" guide (seriously, folks :).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 13 21:40:18 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:56 2004
Subject: Separating documents in a stream
In-Reply-To: kragen@pobox.com's message of "Sat, 13 Nov 1999 16:19:39 -0500 (EST)"
References: <Pine.GSO.4.10.9911131616450.5287-100000@kirk.dnaco.net>
Message-ID: <m3aeoif4wh.fsf@localhost.localdomain>

kragen@pobox.com (Kragen Sitaker) writes:

> One protocol I remember reading about uses ]]>]]> to separate XML
> documents, since that's a sequence that can't occur inside a legal XML
> document.

True, but ^L (formfeed) is not allowed within an XML document either
-- it's still my favourite as a separator.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rja at arpsolutions.demon.co.uk  Sat Nov 13 21:55:31 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:16:56 2004
Subject: Separating documents in a stream
References: <Pine.GSO.4.10.9911131616450.5287-100000@kirk.dnaco.net> <m3aeoif4wh.fsf@localhost.localdomain>
Message-ID: <002c01bf2e21$a2ba4ca0$4a5eedc1@arp01>

Provided the xml pi is _always_ used that can be used as the separator and
seems the cleanest approach to me.

----- Original Message -----
From: David Megginson <david@megginson.com>
To: <xml-dev@ic.ac.uk>
Sent: Saturday, November 13, 1999 9:38 PM
Subject: Separating documents in a stream


> kragen@pobox.com (Kragen Sitaker) writes:
>
> > One protocol I remember reading about uses ]]>]]> to separate XML
> > documents, since that's a sequence that can't occur inside a legal XML
> > document.
>
> True, but ^L (formfeed) is not allowed within an XML document either
> -- it's still my favourite as a separator.
>
>
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 14 00:54:56 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:57 2004
Subject: Separating documents in a stream
In-Reply-To: <002c01bf2e21$a2ba4ca0$4a5eedc1@arp01>
Message-ID: <000001bf2e3b$24d8cf40$099918d1@docuverse1>

>Provided the xml pi is _always_ used that can be used as the 
>separator and
>seems the cleanest approach to me.

But which parsers support multiple documents in a stream
without forcing us to do it manually (by converting each
documents into a string and wrapping a stream around it?

We might have to add a paragraph to the SAX 2 spec if we
want this feature to be supported by all the XML parsers.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 00:58:27 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:16:57 2004
Subject: Separating documents in a stream
In-Reply-To: <002c01bf2e21$a2ba4ca0$4a5eedc1@arp01>
Message-ID: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com>

On Sat, 13 Nov 1999, Richard Anderson wrote:

> Provided the xml pi is _always_ used that can be used as the separator and
                   ^^
> seems the cleanest approach to me.

It is not a "processing instruction"!  It is a *declaration*! (cue Baron
von Zeppelin pushing person who called his airship a "balloon" overboard.)


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



From rja at arpsolutions.demon.co.uk  Sun Nov 14 01:51:24 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:16:57 2004
Subject: Is the XML decl a PI ?
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com>
Message-ID: <008701bf2e42$92747c50$4a5eedc1@arp01>

> It is not a "processing instruction"!  It is a *declaration*!

The XML declaration is an indication to the application processing the
document as to what version of the XML spec the following markup conforms
to, what encoding is used, and whether or not there are dependancies of
external entites within the document.  All of those are processing hints
(read PI) for the XML processor, arent they ?

Now, it you can tell me that the XML decl doesn't meet the definition of a
processing instruction as defined by section 2.6 of the spec I'll change my
mind.   To me, the XML declartion is simply a PI that has a special meaning.
Certainly the SAX parser I use reports the XML declaration as a PI which is
obviously very usual.  Is that unusual ?

I will argue the XML spec doesn't define the declaration as a type of PI,
but it does reserve the xml PItarget, and, quickly checking the nearest XML
book on my desk (XML companion by Neil Bradley) that also says it is a PI.

Regards,

Richard A.



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



From pandeng at telepath.com  Sun Nov 14 02:27:20 1999
From: pandeng at telepath.com (Steve Schafer)
Date: Mon Jun  7 17:16:57 2004
Subject: UTF-8 space efficiency
In-Reply-To: <Pine.GSO.4.10.9911131612100.5100-100000@kirk.dnaco.net>
References: <Pine.GSO.4.10.9911131612100.5100-100000@kirk.dnaco.net>
Message-ID: <38431de9.199851419@90.0.0.40>

On Sat, 13 Nov 1999 16:14:48 -0500 (EST), you wrote:

>Do you know which filesystems they are?  

Well, DOS for one. In that case, it's not the file system per se that
has the problem, but many of the standard command-line utilities do.

-Steve


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 06:30:13 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun  7 17:16:57 2004
Subject: Separating documents in a stream 
Message-ID: <00ce01bf2e72$5cd38a20$788410d2@mmm.tigue.com>

Richard Anderson (rja@arpsolutions.demon.co.uk) wrote:
> Provided the xml pi is _always_ used that can be used 
> as the separator and seems the cleanest approach to me.
> 
> ----- Original Message -----
> From: David Megginson <david@megginson.com>
> > kragen@pobox.com (Kragen Sitaker) writes:
> >
> > > One protocol I remember reading about uses ]]>]]> to 
> > > separate XML documents, since that's a sequence that 
> > > can't occur inside a legal XML document.
> >
> > True, but ^L (formfeed) is not allowed within an XML 
> > document either -- it's still my favourite as a separator.

I'd consider using multipart MIME to solve the problem 
of seperating documents in a stream.

Here's the spec:
IETF RFC 1341
Borenstein, N. and Freed, N., 
"MIME (Multipurpose Internet Mail Extensions): Mechanisms for
Specifying and Describing the Format of Internet Message Bodies"
http://www.ietf.org/rfc/rfc1341.txt

Multiparting is well defined, well tested, and there exists free 
compliant software. Also by using technology which is orthogonal 
to XML, implementation code can be re-used.

Here's an example of what multipart looks like:

MIME-Version: 1.0
Content-Type: multipart/digest; boundary="---- next message ----"

------ next message ----

...document 1 goes here ...

------ next message ----

...document 2 goes here...

------ next message ------



There's even a sub-type 'multipart/related' which works well for 
aggregate documents with interlinked parts and a defined root
entity (for example, for HTML email the root is the HTML document 
and it links to the non-root images). multipart/related maintains
the internal links during transfer. XML document are a good
candidate for multipart/related.

Here's the multipart/related spec:
IETF RFC 2112
Levinson, E.,
"The MIME Multipart/Related Content-type"
http://www.ietf.org/rfc/rfc2112.txt

Here's a modified example from the spec. In this example there
are 3 parts: 1 HTML-like doc and 2 JPEGs.

Content-Type: Multipart/Related; 
     boundary=example-2; 
     start="950118.AEBH@XIson.com"
     type="text/xml"

--example-2
Content-Type: text/xml; charset=iso-8859-1;
     declaration="950118.AEB0@XIson.com"
Content-ID: 950118.AEBH@XIson.com
Content-Description: Document

<doc>
This picture was taken by an automatic camera mounted ...
<image file="cid:950118.AECB@XIson.com" />
<para>
 Now this is an enlargement of the area ...
<image file="cid:950118:AFDH@XIson.com" />
</doc>
--example-2
Content-Type: image/jpeg
Content-ID: 950118.AFDH@XIson.com
Content-Transfer-Encoding: BASE64
Content-Description: Picture A

[encoded jpeg image]
--example-2
Content-Type: image/jpeg
Content-ID: 950118.AECB@XIson.com
Content-Transfer-Encoding: BASE64
Content-Description: Picture B

[encoded jpeg image]
--example-2--



-John




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 06:41:57 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun  7 17:16:57 2004
Subject: Separating documents in a stream
Message-ID: <00d001bf2e74$013cf780$788410d2@mmm.tigue.com>

Don Park (donpark@docuverse.com) wrote:
> We might have to add a paragraph to the SAX 2 spec if we
> want this feature to be supported by all the XML parsers.

I do not agree with this. I consider the techniques suggested
earlier in this thread (for example, "^L" or "]]>]]>" to 
demark document seperation) to be hacks. Perhaps useful in 
some situations but definately not candidates for a spec. 

-John



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



From jamesr at steptwo.com.au  Sun Nov 14 07:03:12 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:16:57 2004
Subject: Why do we write standards?
In-Reply-To: <199911121839.MAA02398@bruno.techno.com>
References: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>
 <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>
Message-ID: <4.2.0.58.19991114175658.00ced100@203.41.126.17>

At 05:39 13/11/1999 , Steven R. Newcomb wrote:

>(I'm trying to think who defends XML from creeping scope.  I should
>know the answer to that question, but I don't.)

After some of my (as usual) rabid posts attacking
creeping featurism in XML, I have received a number
of private responses encouraging me.

Let's just say that some of these hold respected
positions in the standards process ... :-)

The question is: why everyone is keeping their
heads down on this topic?

Just a small comment from one who would
like to drive a stake through the heart of
the current "standards" process, and get on
with real work.

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

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



From crism at exemplary.net  Sun Nov 14 09:41:15 1999
From: crism at exemplary.net (Christopher R. Maden)
Date: Mon Jun  7 17:16:57 2004
Subject: Separating documents in a stream
Message-ID: <v01530501b45430fb20ff@[209.157.134.32]>

[Richard Anderson]
>Provided the xml pi is _always_ used that can be used as the separator and
>seems the cleanest approach to me.

... except the XML *declaration* can appear in a document other than at the
beginning:

<![CDATA[<?xml version="1.0"?>]]>

while the other suggested hacks (^L, ]]>]]>) are always illegal anywhere
within an XML document.

>The XML declaration is an indication to the application processing the
>document as to what version of the XML spec the following markup conforms
>to, what encoding is used, and whether or not there are dependancies of
>external entites within the document.  All of those are processing hints
>(read PI) for the XML processor, arent they ?

Except "PI" is a well- and clearly-defined term, and it does not mean
"processing hint".  Careful terminology is important when discussing
defined standards.

>Now, it you can tell me that the XML decl doesn't meet the definition of a
>processing instruction as defined by section 2.6 of the spec I'll change my
>mind.

That would be ?2.6, productions [16] and [17]:

[16] PI       ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

The string '<?xml ...?>' does not match PI because 'xml' does not match
PITarget.

>To me, the XML declartion is simply a PI that has a special meaning.
>Certainly the SAX parser I use reports the XML declaration as a PI which is
>obviously very usual.  Is that unusual ?

I hope it is - that parser is broken.

>I will argue the XML spec doesn't define the declaration as a type of PI,
>but it does reserve the xml PItarget, and, quickly checking the nearest XML
>book on my desk (XML companion by Neil Bradley) that also says it is a PI.

That book is broken too.  That's one reason why careful use of terminology
is important - you may know what you meant, but in a public forum, others
will learn from what you say, and they may not know what you meant (though
they think they do).

The prose language is ?2.6 is a little ambiguous, noting that "XML", "xml",
and so on are reserved for standardization.  However, the grammar for
PITarget explicitly forbids them; compare ?2.3, where Names beginning with
xml are reserved, but the grammar permits them.

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 12:29:11 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:57 2004
Subject: The XML decl is not a PI (especially in SAX)
In-Reply-To: "Richard Anderson"'s message of "Sun, 14 Nov 1999 01:49:27 -0000"
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com> <008701bf2e42$92747c50$4a5eedc1@arp01>
Message-ID: <m34sepfeai.fsf_-_@localhost.localdomain>

"Richard Anderson" <rja@arpsolutions.demon.co.uk> writes:

> The XML declaration is an indication to the application processing
> the document as to what version of the XML spec the following markup
> conforms to, what encoding is used, and whether or not there are
> dependancies of external entites within the document.  All of those
> are processing hints (read PI) for the XML processor, arent they ?

Here are the productions for a processing instruction in XML 1.0:

[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

The XML and text declarations cannot match this production -- the only 
reason that the syntax is similar is so that XML could work with
legacy SGML tools.

> Certainly the SAX parser I use reports the XML declaration as a PI
> which is obviously very usual.  Is that unusual ?

That is wrong.  Note the documentation from DocumentHandler.java:

    * Receive notification of a processing instruction.
    *
    * <p>The Parser will invoke this method once for each processing
    * instruction found: note that processing instructions may occur
    * before or after the main document element.</p>
    *
    * <p>A SAX parser should never report an XML declaration (XML 1.0,
    * section 2.8) or a text declaration (XML 1.0, section 4.3.1)
    * using this method.</p>

Please inform the author of the parser of this implementation bug.

> I will argue the XML spec doesn't define the declaration as a type
> of PI, but it does reserve the xml PItarget, and, quickly checking
> the nearest XML book on my desk (XML companion by Neil Bradley) that
> also says it is a PI.

That book is also wrong -- please inform the author.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From liamquin at interlog.com  Sun Nov 14 14:10:59 1999
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:16:57 2004
Subject: The XML decl is not a PI (especially in SAX)
In-Reply-To: <m34sepfeai.fsf_-_@localhost.localdomain>
Message-ID: <Pine.BSI.3.96r.991114090358.25573A-100000@shell1.interlog.com>

On 14 Nov 1999, David Megginson wrote:
> "Richard Anderson" <rja@arpsolutions.demon.co.uk> writes:
> > Certainly the SAX parser I use reports the XML declaration as a PI
> > which is obviously very usual.  Is that unusual ?
> 
> That is wrong.  Note the documentation from DocumentHandler.java:
[...]

> > and, quickly checking
> > the nearest XML book on my desk (XML companion by Neil Bradley) that
> > also says it is a PI.
> 
> That book is also wrong -- please inform the author.

When Ian and I were working on "The XML Specification Guide" last year,
I seem to remember noticing that if there was any leading whte space
or a comment before the XML declaration, it becomes instead a
processing instruction that happens to use the reserved target "xml".

The spec does not explicitly forbid this.

Richard, check that your documents have <?xml... right at the very start.

Any good XML book should make very clear the difference between the
XML declaration and a processing instruction -- I agree wth David!!

Lee

-- 
Liam Quin, Barefoot Computing, Toronto;  The barefoot agitator
liam at vex . net        http://www.valinor.sorcery.net/~liam/
co-author, "The XML Specification Guide", Wiley, 1999
Ankh on irc.sorcery.net


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



From gtn at ebt.com  Sun Nov 14 15:48:37 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:16:57 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <3.0.32.19991113113706.01335d90@pop.intergate.ca>
Message-ID: <000101bf2eb7$613ec620$015110ac@eps.inso.com>

coding as long as you 
> declare it.  I'm
> delighted to observe that most of the real-world XML 
> processors out there
> effortlessly deal with various ISO-Latins and JIS and so on. -T.

Right. One main point of the HTML 4.0 SGML declaration was
to allow this for HTML... practically, it will be many years
before the majority of data is in utf-*.


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



From clark.evans at manhattanproject.com  Sun Nov 14 16:01:42 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:16:57 2004
Subject: APIs vs Markup
In-Reply-To: <3.0.32.19991113113844.014a5310@pop.intergate.ca>
Message-ID: <Pine.LNX.4.10.9911141100590.12239-100000@cantor.clarkevans.com>

On Sat, 13 Nov 1999, Tim Bray wrote:
> For things like log files, just treat 'em as a succession 
> of small XML documents.  Is this a problem? -T.

This does not work all that well with XSL and DOM,
since the xpath syntax allows access to the whole
document; hence most implementations of tools will
try to read in the entire "document" before proceeding.

I liked John Tigue's suggestion of
using MIME for this purpose.  Perhaps a SAX 
parser should be able to read MIME?

Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 14 16:39:20 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:57 2004
Subject: The XML decl is not a PI (especially in SAX)
Message-ID: <004c01bf2ec2$19f73df0$33f96d8c@NT.JELLIFFE.COM.AU>

The XML header could be a PI tag based on its delimiters, but it is not
by definition. James Clark has picked me up on this a few times: he is
so tough. The XML header is stripped as a function of entity management.

However, even though the encoding attribute in the XML header does not
form part of the information set of  a document, I think it is a mistake
to think that it should be discarded after the parsing of a document.

On the contrary, I think applications should operate so that, by
default, the output encoding of documents matches the input encoding (of
the root entity, unless the root entity is ASCII and subentities use
some other ASCII-superset encoding, in which case that encoding should
be used.)

I hope that future APIs could keep this in mind: hide the encoding from
the processor by all means, but save the encoding information for
re-encoding later.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 18:27:35 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:16:57 2004
Subject: Is the XML decl a PI ?
Message-ID: <3.0.32.19991114102708.0132fd00@pop.intergate.ca>

At 01:49 AM 11/14/99 -0000, Richard Anderson wrote:
>> It is not a "processing instruction"!  It is a *declaration*!
>
>The XML declaration is an indication to the application processing the
>document as to what version of the XML spec the following markup conforms
>to, what encoding is used, and whether or not there are dependancies of
>external entites within the document.  

This is true.

But it's my opinion that the XML decl is *not* a PI, for three reasons:

 - it doesn't match production [17] because the target is 'xml'
 - it doesn't match sections [22] and [27], which says that a PI
   can only occur in the space starting *after* the XML declaration
 - section 2.6 says "Processing instructions (PIs) allow documents to 
   contain instructions for applications. ".  The XML decl contains 
   instructions for the XML processor which is carefully distinguished
   from an application

But I think the spec probably should have had an explicit statement
saying that the XML decl either is or isn't a PI, because it admittedly
kind of walks, swims, and quacks like one. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rja at arpsolutions.demon.co.uk  Sun Nov 14 18:26:28 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:16:57 2004
Subject: Are you sure the XML decl shouldnt be a PI ? :)
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com> <008701bf2e42$92747c50$4a5eedc1@arp01> <m34sepfeai.fsf_-_@localhost.localdomain>
Message-ID: <006101bf2ecd$8b434c00$4a5eedc1@arp01>

> [16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
> [17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
> The XML and text declarations cannot match this production -- the only
> reason that the syntax is similar is so that XML could work with
> legacy SGML tools.

Given the spec says PItargets starting with xml are reserved for
standazation in this or future versions of the spec, I'd personally say it
should be considered a PI with special meaning, why else reserve the
characters in the PI declartion ?  I can appreicate the SGML links (although
I've never used SGML) but it just seems strange to have exclusion clauses.
Also, the xml-stylesheet association is currently using a processing
instruction, so why no the XML decl too?  Dont tell, thats not a PI either,
or it will be called stylesheet declartion in the next XML spec  ;)

Another reason why I think it should be regarded as a PI...

If I using the DOM how do I specify the XML decl ? Using MSXML and other
implementations I've used  I create a PI and add it to the document, seems
very logical to me, so why confuse the issue ?

I know alot of Java people lwho don't use MSXML on this list, so please let
me know how you do it in your implementations.

> Please inform the author of the parser of this implementation bug.

I think it is a very useful feature, how else can I know the encoding ?
Using SAX 2 I guess we could add this as a feature using the URI techniques.
Still, I want the PI reporting in SAX1 so I'm happy to wonder from  the spec
for now if it achieves my goals and others.  Others must be happy with this
solution too, otherwise people wouldnt ever tools that dont conform.

> That book is also wrong -- please inform the author.

I cant see anywhere in the XML spec that says the XML dec is not a PI, or
vice-versa, so I don't feel compelled to do that just yet.  Maybe later
though when you hammer me with your next response ;)

Best Regards,

Richard.
----- Original Message -----
From: David Megginson <david@megginson.com>
To: <xml-dev@ic.ac.uk>
Sent: Sunday, November 14, 1999 12:28 PM
Subject: The XML decl is not a PI (especially in SAX)


> "Richard Anderson" <rja@arpsolutions.demon.co.uk> writes:
>
> > The XML declaration is an indication to the application processing
> > the document as to what version of the XML spec the following markup
> > conforms to, what encoding is used, and whether or not there are
> > dependancies of external entites within the document.  All of those
> > are processing hints (read PI) for the XML processor, arent they ?
>
> Here are the productions for a processing instruction in XML 1.0:
>
> [16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
> [17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
>
> The XML and text declarations cannot match this production -- the only
> reason that the syntax is similar is so that XML could work with
> legacy SGML tools.
>
> > Certainly the SAX parser I use reports the XML declaration as a PI
> > which is obviously very usual.  Is that unusual ?
>
> That is wrong.  Note the documentation from DocumentHandler.java:
>
>     * Receive notification of a processing instruction.
>     *
>     * <p>The Parser will invoke this method once for each processing
>     * instruction found: note that processing instructions may occur
>     * before or after the main document element.</p>
>     *
>     * <p>A SAX parser should never report an XML declaration (XML 1.0,
>     * section 2.8) or a text declaration (XML 1.0, section 4.3.1)
>     * using this method.</p>
>
> Please inform the author of the parser of this implementation bug.
>
> > I will argue the XML spec doesn't define the declaration as a type
> > of PI, but it does reserve the xml PItarget, and, quickly checking
> > the nearest XML book on my desk (XML companion by Neil Bradley) that
> > also says it is a PI.
>
> That book is also wrong -- please inform the author.
>
>
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Sun Nov 14 18:46:35 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:16:58 2004
Subject: HERE's why the world needs a simpler XML! [was Re: The XML decl is not a PI (especially in SAX)]
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com> <008701bf2e42$92747c50$4a5eedc1@arp01> <m34sepfeai.fsf_-_@localhost.localdomain>
Message-ID: <016101bf2ecf$c6d0e4b0$421e12d1@PTGRESTON>


----- Original Message -----
From: David Megginson <david@megginson.com>
To: <xml-dev@ic.ac.uk>
Sent: Sunday, November 14, 1999 7:28 AM
Subject: The XML decl is not a PI (especially in SAX)


> Here are the productions for a processing instruction in XML 1.0:
>
> [16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
> [17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
>
> The XML and text declarations cannot match this production -- the only
> reason that the syntax is similar is so that XML could work with
> legacy SGML tools.

[snip]

> That book is also wrong -- please inform the author.
>

Sigh.  I'm sure David Megginson is right ... but doesn't this illustrate a
big point that Don Park has been making?  We've got this thing that looks
like a PI to the casual observer, and even people who've looked at the
subject deeply enough to write a book about XML have gotten confused!

I suspect that either the "XML community" will work together on a
simplification of XML that makes it more accessible to the kinds of people
who've been writing HTML in Notepad for the last few years ... or somebody
else will ... or worse yet, a kindof "de facto lowest common denominator"
flavor of XML will get loosely defined by various vendors who don't want to
impose this kind of stuff on their customers.

[duck  ;~)  ]

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rja at arpsolutions.demon.co.uk  Sun Nov 14 19:31:49 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:16:58 2004
Subject: The XML decl is not a PI (especially in SAX)
References: <004c01bf2ec2$19f73df0$33f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <00fa01bf2ed6$b1058030$4a5eedc1@arp01>

> The XML header could be a PI tag based on its delimiters, but it is not
> by definition. James Clark has picked me up on this a few times: he is
> so tough. The XML header is stripped as a function of entity management.

I agree.

> However, even though the encoding attribute in the XML header does not
> form part of the information set of  a document, I think it is a mistake
> to think that it should be discarded after the parsing of a document.

I agree 110%

> I hope that future APIs could keep this in mind: hide the encoding from
> the processor by all means, but save the encoding information for
> re-encoding later.

Yes.  I'd go further and say the processor should have the option to see the
encoding. For example, given 1 XML input stream I should be able to create 5
outputs, which each output in the same encoding as the original input if so
desired.

Regards,

Richard.
>
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 21:07:51 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:16:58 2004
Subject: Why do we write standards?
References: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>
	 <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk> <4.2.0.58.19991114175658.00ced100@203.41.126.17>
Message-ID: <382F248A.997F8A08@pacbell.net>

James Robertson wrote:
> 
> At 05:39 13/11/1999 , Steven R. Newcomb wrote:
> 
> >(I'm trying to think who defends XML from creeping scope.  I should
> >know the answer to that question, but I don't.)
> 
> After some of my (as usual) rabid posts attacking
> creeping featurism in XML, I have received a number
> of private responses encouraging me.
> 
> Let's just say that some of these hold respected
> positions in the standards process ... :-)
> 
> The question is: why everyone is keeping their
> heads down on this topic?

There's the "volume of traffic on XML-DEV" issue,
which can affect even just keeping up with traffic.

Also, agreeing with self-evident truths isn't
always an effective way to invest time ... :-)

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 14 22:40:09 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:16:58 2004
Subject: Are you sure the XML decl shouldnt be a PI ? :)
In-Reply-To: "Richard Anderson"'s message of "Sun, 14 Nov 1999 17:29:32 -0000"
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com> <008701bf2e42$92747c50$4a5eedc1@arp01> <m34sepfeai.fsf_-_@localhost.localdomain> <006101bf2ecd$8b434c00$4a5eedc1@arp01>
Message-ID: <m39040pujk.fsf@localhost.localdomain>

"Richard Anderson" <rja@arpsolutions.demon.co.uk> writes:

> Given the spec says PItargets starting with xml are reserved for
> standazation in this or future versions of the spec, I'd personally say it
> should be considered a PI with special meaning, why else reserve the
> characters in the PI declartion ?

For xml-stylesheet, etc.  An earlier version of the Namespaces in XML
spec used a processing instruction xml-namespace.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 02:19:35 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:16:58 2004
Subject: Are you sure the XML decl shouldnt be a PI ? :)
In-Reply-To: <m39040pujk.fsf@localhost.localdomain>
Message-ID: <000501bf2f10$1baf03a0$099918d1@docuverse1>

This is why like the SML idea.  My usual style of
designing is to wack off anything that causes
confusion.  Wacking off both PI and XML declaration
leaves me two less things to be confused about.

Even if UTF-16 support is thrown into SML, it is
fairly easy to differentiate UTF-8 and UTF-16 so
there is no need for XML declaration.  Lack of
version information prevents future feature creeping
problem as well.  Sort of masocistic approach to
engineering. <g>

WARNING: Don't try this at home.  You might end up
being an enuch.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Mon Nov 15 06:25:38 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:16:58 2004
Subject: The XML decl is not a PI (especially in SAX)
In-Reply-To: <00fa01bf2ed6$b1058030$4a5eedc1@arp01>
Message-ID: <000a01bf2f31$9df279c0$015110ac@eps.inso.com>

> > I hope that future APIs could keep this in mind: hide the
> > encoding from the processor by all means, but save the encoding
information for
> > re-encoding later.
>
> Yes.  I'd go further and say the processor should have the
> option to see the encoding.

Perhaps in something like the SAX API, there would be some of this
information passed along... it is useful information for many things.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 06:15:04 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:16:58 2004
Subject: HERE's why the world needs a simpler XML! [was Re: The XML decl is not a PI (especially in SAX)]
Message-ID: <002401bf2f33$f90e6150$45f96d8c@NT.JELLIFFE.COM.AU>


From: Michael Champion <Mike.Champion@softwareag-usa.com>

>Sigh.  I'm sure David Megginson is right ... but doesn't this
illustrate a
>big point that Don Park has been making?  We've got this thing that
looks
>like a PI to the casual observer, and even people who've looked at the
>subject deeply enough to write a book about XML have gotten confused!

But is it an important confusion?

In C we have types int and long and short and so on: but we only have
char and wchar_t.  Programmers have been trained that storage of
characters is important but a knowledge of the sets they use is not.  So
many or most programmers simply do not have any idea about
encodings/repertoires/collections/sets or characters/glyphs etc.

This collosal ignorance of the tools of our trade means that in order to
understand the XML header people must be given a little non-scary primer
on character encodings. The issue of whether it is a PI or not is
certainly relevent, because it is a major plus for XML if the encoding
is not considered part of the information set (which is not to say that
it should be thrown away, as mentioned).

On this issue, I think the books on XML and the various implementations
have been excellent; if one XML implementation keeps it as a PI and if
one book uses the term for this loosely, it is perhaps the most minor
flaw that is imaginable.  99.999% of users will not care whether it is a
PI or not; but at least 99% will care that multiple encodings are
supported well and richly on input and output.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 10:14:07 1999
From: mtbryan at sgml.u-net.com (Martin Bryan)
Date: Mon Jun  7 17:16:58 2004
Subject: external parsed entites (was: A unique ID question ?)
Message-ID: <013d01bf2f52$440d2880$36c566c3@unet.com>

Ken Holman wrote:

>I, for one, hope external parsed entities *do not* go away.

>I need them when I need to handle *one* XML file in *many* small manageable
pieces ... I don't need them for re-use or for sharing, but they provide a
useful convenience.

The key reason for needing external parsed entities is "manageability".
Large documents are not written as monoliths. They are written and reviewed
in sections, with different teams often being used to create and comment on
different sections. If the document needs to be translated this often needs
to be done in sections as well, rather than waiting for the completion of
the last page of the document before you can start translation. The fact
that sections of the final document need to be able to cross refer to each
other requires the use of a global ID scheme, but this is easy to do with
appropriate management of the names that are used to create IDs. Here
namespaces can be of assistance.

Let's not throw out the baby with the bath water. Until we have a decent
subdocument/embedded link mechanism that has been taken up by a wide range
of tools we *need* to retain external parsed entities in XML

Martin Bryan




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



From kamiya at rp.open.cs.fujitsu.co.jp  Mon Nov 15 11:27:08 1999
From: kamiya at rp.open.cs.fujitsu.co.jp (Takuki Kamiya)
Date: Mon Jun  7 17:16:58 2004
Subject: ANNOUNCE: XPath interface for XT Version 0.85
Message-ID: <03dc01bf2f5c$52155650$866e230a@sysrap.cs.fujitsu.co.jp>

I have written an DOM query utility in Java on top of XT.
You can use it to retrieve DOM Nodes that matches to a given XPath selector.
I share the code with the community for free to see if anyone finds it useful.

Download from http://www.246.ne.jp/~kamiya/pub/omquery.zip .

Free with no warranty. Comments are welcome. Any feedback are invited.

= Takuki Kamiya  Phone: (045)476-4586 Fax: (045)476-4749   =
= FUJITSU LIMITED (COINS:7128-4217 NIFTY:HHA01731)         =


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



From sriroop at excite.com  Mon Nov 15 12:09:27 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667706.9871.846@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:22:55 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667738.18024.6@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:15 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667692.25424.663@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:22 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667699.14744.232@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:26 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667703.29538.659@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:22:53 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667708.29623.909@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:16 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:58 2004
Subject: XML for Data Transfer
Message-ID: <942667693.15500.84@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:11 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667691.11084.33@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:12:56 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667710.27150.563@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:20 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667694.10048.447@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:24 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667700.25499.157@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:08 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667685.18305.391@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:09:27 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667705.13484.275@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:13:00 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667714.1030.461@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:12:05 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667690.7908.160@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:22:48 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667711.24723.307@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:12:53 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667707.325.21@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:12:42 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667705.25898.65@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:20:31 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942668366.25749.207@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sriroop at excite.com  Mon Nov 15 12:22:51 1999
From: sriroop at excite.com (roopa rayaprolu)
Date: Mon Jun  7 17:16:59 2004
Subject: XML for Data Transfer
Message-ID: <942667712.7802.39@excite.com>

I am new to XML and have been looking at various web sites for some help,
but so far have not found anything that helps me with my requirements. 
       Most of the info I have found has been related to displaying data
from XML in a document or web page. I am interested in taking data from a
file in XML format and using Java as application, writing data to a
database. I am ok about the Java and database side of things but am puzzled
about how to get data from a file in XML form - do I need a "parser" or do I
write my own code to read the XML and extract the data items? 
      Can anyone point me in the right direction for using XML in this way
rather than for display purposes? 
      If possible, can anyone give a coded example for this thing?

Thanx in advance.
sriroop




________________________________________________________________
Get FREE voicemail, fax and email at http://voicemail.excite.com
Talk online at http://voicechat.excite.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kantps at yahoo.com  Mon Nov 15 12:52:16 1999
From: kantps at yahoo.com (srikanth pillalamarri)
Date: Mon Jun  7 17:16:59 2004
Subject: No subject
Message-ID: <19991115124447.26314.rocketmail@web121.yahoomail.com>


unsubscribe xml-dev digest srikanth pillalamarri

=====

__________________________________________________
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kantps at yahoo.com  Mon Nov 15 12:52:19 1999
From: kantps at yahoo.com (srikanth pillalamarri)
Date: Mon Jun  7 17:16:59 2004
Subject: No subject
Message-ID: <19991115124455.13463.rocketmail@web125.yahoomail.com>


unsubscribe xml-dev digest srikanth pillalamarri

=====

__________________________________________________
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kantps at yahoo.com  Mon Nov 15 12:51:40 1999
From: kantps at yahoo.com (srikanth pillalamarri)
Date: Mon Jun  7 17:16:59 2004
Subject: No subject
Message-ID: <19991115124418.26401.rocketmail@web107.yahoomail.com>


subscribe xml-dev srikanth pillalamarri

=====

__________________________________________________
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 13:28:43 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:16:59 2004
Subject: Profiling and Packaging XML
Message-ID: <199911151327.IAA01701@hesketh.net>

It seems like everyone has their own list of favorite features in XML, as
well as a list of features whose inclusion in XML they consider heretical.
(The W3C, for instance, doesn't seem very happy about processing
instructions, based on some statements in things like the style sheet PI
Rec.)  

Since the SGML declaration was first against the wall (mostly an excellent
thing), we don't have any way whatsoever to indicate that features are
required, optional, or prohibited.  We don't even have a way to indicate
that documents might, for instance, require validating parsers to avoid
losing the 99.9% of their content that happens to reside in external
resources.  (I've done a lot of work on this in XML Processing Description
Language, XPDL, at http://purl.oclc.org/NET/xpdl, but figure my work will
show up in some other project at best.)

It sounds like the W3C is pondering XML packaging in round III of the XML
Activity.  Might this be a good time to discuss what kinds of information
we'd like to see in those packages?  Does profiling seem like a useful
tool?  It seems like it might allow developers to specify rules like 'no
external entities', 'no PIs', and 'no namespaces' for particular
applications, and let us all have our opinions but not necessarily inflict
them on everyone else's parsing.

(I suspect that everyone will actually continue to use XML 1.0 parsers
rather than write their own, but I don't think that reduces the need for
documenting such profiles.)

Phew!  A week away from XML-dev.  Lots of messages, almost all of them
interesting.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From robertl1 at home.com  Mon Nov 15 14:00:27 1999
From: robertl1 at home.com (Robert La Quey)
Date: Mon Jun  7 17:16:59 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <000201bf2c4b$6a56b560$099918d1@docuverse1>
Message-ID: <3.0.6.32.19991115055354.03ee5a50@mail.dt1.sdca.home.com>

At 05:48 AM 11/11/99 -0800, you wrote:
>Everyone,
>
>I have been thinking that there are applications out there that
>can benefit from using XML yet donot need all of its features.
>The Canonical XML spec goes quite a distance in cutting away
>some of the features, for different purpose, but I still feel
>that more can be cut away.  Rick Jelliffe's rather funny
>message along with some WebDAV papers I read over the weekend
>got my mind buzzing enough for me to share this idea with the
>rest of XML-DEV.
>
>What I have in mind is a subset of XML, I'll call it Simple
>(or Stupid) Markup Language (SML) for now, that simplifies XML
>down to the bare essentials.  Ideally, it should also be a
>subset of Canonical XML.  Here are some ideas:
>
>o No Attributes (ouch!)
>o No PI, Comments, Notations, or CDATA sections
>o No document type declaration
>o UTF-8 encoding only
>o No non-character entity references
>o No predefined character entities (I am iffy on this one)
>
>What do you guys think?  Please do not get caught up with
>the list I presented above because they are just ideas and
>subject to change later depending on your capacity to scream
>convincingly.  The key point to consider is whether there is
>a broad enough need for such a subset of XML.
>
>Best,

OK, enough lurking. I would like to pick this thread back up 
from the beginning and restart the discussion with a call for
opinions from another crowd who seem (to me) conspicuously missing
from the discussion. Are there any other lurkers in 
this group who have interest in the HDML->WML->XML=SML story?

i.e. XML from the point of view of a very small systems (embedded)
perspective. I think the SGML->XML crowd has pretty well stated
their reasons for disliking SML. My own opinion is this. SML will
happen (perhaps as WML, perhaps as many SMLs, a 1000 flowers bloom) 
as a de facto reality in arenas where fast product time to market 
and young engineers dominate the scene. 

As for lots of users. Ha! The largest cell phone community is already 
China with 25 Million users (UTF-8???). So the SML question they pose, 
while very different from the SGML world of woe and complexity, is perhaps 
of some importance. 

Is the overlap into the XML world worth pursuing or should the WML
world just go its own way? 

Comments? 

Bob La Quey
Bob La Quey

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov 15 16:30:27 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.6.32.19991115055354.03ee5a50@mail.dt1.sdca.home.com>
Message-ID: <04af01bf2f85$b794ee90$421e12d1@PTGRESTON>


----- Original Message -----
From: Robert La Quey <robertl1@home.com>
To: <xml-dev@ic.ac.uk>
Cc: Don Park <donpark@docuverse.com>
Sent: Monday, November 15, 1999 8:53 AM
Subject: Re: Feeler for SML (Simple Markup Language)


> Are there any other lurkers in
> this group who have interest in the HDML->WML->XML=SML
> story?

Well, I haven't exactly been lurking on this thread, but this is *exactly*
why I'm interested in "SML".  My employer is a database and enterprise tool
vendor that recently announced a strategic relationship with Nokia to help
make enterprise data available to WML-based applications.  I'm trying to
sort out how to best leverage our XML database technology and other XML
tools to help accomplish this.

> My own opinion is this. SML will
> happen (perhaps as WML, perhaps as many
> SMLs, a 1000 flowers bloom)
> as a de facto reality in arenas where fast product time to market
> and young engineers dominate the scene.

Again, that's exactly my concern here.  I'd like to see 1000 flowers growing
out of a specific subset of XML or the XML APIs rather than 1000 weeds
proliferating wherever natural selection takes them ;~)

> Is the overlap into the XML world worth pursuing or should the WML
> world just go its own way?

I hope that the WML world will be patient, learn from the XML world,
and try to work out a rational scheme for taking what is useful from
XML and gracefully ignoring that which is irrelevant.  For example, WML
itself is very analogous to HTML in that that markup is about appearance
rather than meaning.  Learn from the HTML->XML evolution in the Web as a
whole, don't repeat the mistake of failing to separate form from content!
Display XML data in WML (or HTML, or HDML, or whatever), but don't author or
store data in a specific display format.

Likewise I hope the SGML->XML world will understand that the same dynamics
that drove the evolution from SGML to XML are still at work -- simplicity,
conceptual clarity, and scalability are the characteristics of XML that the
people in the EDI and WML worlds care about . They don't care about
minimizing the differences between XML and SGML, they don't want to be
burdened with supporting markup or APIs that they will never need, they just
need somethat that works for them ... and will either "go their own way" or
go in a hundred different ways if the XML world doesn't meet them halfway.






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



From matthew at praxis.cz  Mon Nov 15 16:27:19 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.6.32.19991115055354.03ee5a50@mail.dt1.sdca.home.com>
Message-ID: <38303440.C04627FB@praxis.cz>

To me this post is a perfect illustration of why something like SML is
not necessary or desirable. In terms of necessity, it seems more than
likely that embedded and handheld devices are going to work with a
specific XML application (e.g. WML) rather than providing generic XML
processing services. So as long as this application does not use the
features listed in Don's original post, the issues of memory consumption
and processing speed vanish (and I am sceptical as to how significant
these issues would be anyway). In the event, WML uses comments and CDATA
but no processing instructions.

In terms of desirability, Tim hit the nail on the head. Bifurcating into
two distinct languages can only be a bad thing for the overall impact of
XML. The risk of confusion is simply too high. As several others have
pointed out, the existence of too many varying levels of conformance (de
facto if not de jure) and optional features in SGML was the primary
motivation for inventing XML in the first place.

Matthew

Robert La Quey wrote:
> OK, enough lurking. I would like to pick this thread back up
> from the beginning and restart the discussion with a call for
> opinions from another crowd who seem (to me) conspicuously missing
> from the discussion. Are there any other lurkers in
> this group who have interest in the HDML->WML->XML=SML story?
> 
> i.e. XML from the point of view of a very small systems (embedded)
> perspective. I think the SGML->XML crowd has pretty well stated
> their reasons for disliking SML. My own opinion is this. SML will
> happen (perhaps as WML, perhaps as many SMLs, a 1000 flowers bloom)
> as a de facto reality in arenas where fast product time to market
> and young engineers dominate the scene.
> 
> As for lots of users. Ha! The largest cell phone community is already
> China with 25 Million users (UTF-8???). So the SML question they pose,
> while very different from the SGML world of woe and complexity, is perhaps
> of some importance.
> 
> Is the overlap into the XML world worth pursuing or should the WML
> world just go its own way?
> 
> Comments?
> 
> Bob La Quey

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 16:36:08 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:00 2004
Subject: Schematron: Rick Jelliffe interview on xmlhack
Message-ID: <199911151635.LAA11555@hesketh.net>

We just posted an interview with Rick Jelliffe on http://www.xmlhack.com,
discussing the latest on Schematron developments, how it works, how it fits
with XML Schemas, and even where the name came from.

If you've followed Rick's discussions on XML-dev, or if you're intrigued by
the prospect of an XPath-based schema language, I hope you'll enjoy the
interview.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From schampeo at hesketh.com  Mon Nov 15 17:24:34 1999
From: schampeo at hesketh.com (Steven Champeon)
Date: Mon Jun  7 17:17:00 2004
Subject: DTD for rfc822 messages?
Message-ID: <Pine.LNX.3.95.991115121728.8934I-100000@wasabi.hesketh.net>


Hello -

I've searched the archives for xml-dev and xml-l, looking for a DTD with
which to markup archived email, and stumbled across a couple of posts:

 http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1998/0802.html
 http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1998/0805.html

If I understand the approach being recommended, the DTD would contain a
unique element for every possible header, which would seem to present
some serious maintenance headaches, especially for non-standard headers.
I'd think something like this would make more sense:

<hdr type="Received" value="...">
<hdr type="Received" value="...">
<hdr type="From" value="some@one.com">
<hdr type="Subject" value="Re: the original subject">

but I could be wrong. For one thing, that may make it more difficult to
write XSL templates that process the info inside each hdr element. Comments?

Has any more work been done on such a DTD? I looked at schema.net and
the various XML sites, but found nothing appropriate. If this is more
appropriate for XML-L, could someone let me know?

TIA,
Steve
-- 
business: http://hesketh.com ...custom medium- to large-scale web sites
the book: http://dhtml-guis.com  ...Building Dynamic HTML GUIs from IDG
punditry: http://a.jaundicedeye.com       ...negative forces have value
personal: http://hesketh.com/schampeo/  ...info, projects, random stuff


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 15 17:23:03 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca>

At 11:23 AM 11/15/99 -0500, Michael Champion wrote:
>Likewise I hope the SGML->XML world will understand that the same dynamics
>that drove the evolution from SGML to XML are still at work -- simplicity,
>conceptual clarity, and scalability are the characteristics of XML that the
>people in the EDI and WML worlds care about . They don't care about
>minimizing the differences between XML and SGML, they don't want to be
>burdened with supporting markup or APIs that they will never need, they just
>need somethat that works for them ... and will either "go their own way" or
>go in a hundred different ways if the XML world doesn't meet them halfway.

So what do you recommend?  Specifically please.

My feeling is that XML 1.0 as it exists now works OK for EDI.  Yes, it
could have a lot less and still work for EDI, but the extras don't seem
to get actively in the way.

As for the WML world, the WAP-folk have apparently taken the decision that 
none of IP/HTTP/HTML/XML are appropriate for them without significant rework.
Anyone is free to disagree, but they're the ones building the cellphones.

I don't think that the EDI and WAP use-cases are really in the same
place on the map.  -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov 15 17:39:08 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.6.32.19991115055354.03ee5a50@mail.dt1.sdca.home.com> <38303440.C04627FB@praxis.cz>
Message-ID: <002c01bf2f8f$4fc48050$e5bdb3c7@PTGRESTON>


----- Original Message -----
From: Matthew Gertner <matthew@praxis.cz>
To: <xml-dev@ic.ac.uk>
Sent: Monday, November 15, 1999 11:26 AM
Subject: Re: Feeler for SML (Simple Markup Language)


> In terms of necessity, it seems more than
> likely that embedded and handheld devices are going to work with a
> specific XML application (e.g. WML) rather than providing generic
> XML processing services.

The problem I see is that handhelds may use WML *today* as a simple display
format, but historically simple display devices have tended to acquire
intelligence.  I fear that full-blown XML will be too heavy for such
devices, so the vendors will invent their own subsets.  So we may end up
with the worst of both worlds .. rather than bifurcation of the standard,
we'll have multiplication of all sorts of non-standard variants.

Remember 1995-1997 in the HTML Web ... It saw HTML become its own "world"
totally distinct from its SGML roots, and it saw numerous incompatible
variants of HTML proliferate. This could happen again, this time with XML as
the creaky old "bloated" standard that doesn't fit the needs of the
fast-moving innovators.  I'm not at all sure that "SML" could prevent that,
but I see the same complaints about XML and the DOM API (pretty much the
points that Don made in the original post) again and again among people
trying to use it in light client or high performance applications.

Bifurcation is not as desireable as unification, but it beats chaos!





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 17:47:15 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca>
Message-ID: <3.0.6.32.19991115173548.009256d0@gpo.iol.ie>

>
>My feeling is that XML 1.0 as it exists now works OK for EDI.  Yes, it
>could have a lot less and still work for EDI, but the extras don't seem
>to get actively in the way.
>

I would argue they do get actively in the way.
Sure, the EDI stuff probably does not need external parsed entities
and who knows what else. But if EDI software is going to
truthfully "use XML" and "be fully XML compliant" then it
cannot just barf when these things appear in XML docs.

And as Simon St. Laurent said just recently, there is no formal
way to declare what XML features your software handles and
what bits it doesn't handle.




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



From matthew at praxis.cz  Mon Nov 15 17:54:50 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca>
Message-ID: <383048C2.AFABE24F@praxis.cz>

Tim Bray wrote:
> As for the WML world, the WAP-folk have apparently taken the decision that
> none of IP/HTTP/HTML/XML are appropriate for them without significant rework.
> Anyone is free to disagree, but they're the ones building the cellphones.

Did I miss something? I have the June 99 WML draft sitting on my desk,
and while I haven't checked every detail, it looks pretty close to a
conformant XML app. There might be some problems with character encoding
and the XML declaration (or lack thereof), but I would hardly call this
"significant rework".

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 15 17:56:43 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <3.0.32.19991115095732.01337e50@pop.intergate.ca>

At 05:35 PM 11/15/99 +0000, Sean Mc Grath wrote:
>>My feeling is that XML 1.0 as it exists now works OK for EDI.  Yes, it
>>could have a lot less and still work for EDI, but the extras don't seem
>>to get actively in the way.
>
>I would argue they do get actively in the way.
>Sure, the EDI stuff probably does not need external parsed entities
>and who knows what else. But if EDI software is going to
>truthfully "use XML" and "be fully XML compliant" then it
>cannot just barf when these things appear in XML docs.

Hmm.... just specify the use of a nonvalidating processor.  These have the 
right to ignore external entities, not to barf, just to ignore them.  If
the system is specified in this way, nobody will send external entities.
(Which lord knows they shouldn't be doing in ecommerce-land anyhow).

Next problem? -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ypatil at kingston.hummingbird.com  Mon Nov 15 18:01:18 1999
From: ypatil at kingston.hummingbird.com (Yogita Patil)
Date: Mon Jun  7 17:17:00 2004
Subject: Need a favour - anyone ?
Message-ID: <03c901bf2f93$723de460$1a02060a@andyne.com>

Can anyone verify the bits of xml/xsl/dtd for me ? Also could you point out stuff that is not needed or extra or if i'm correct.

DTD:
<!ELEMENT root (elements+)>
<!ELEMENT elements (label*)>
<!ELEMENT label (plaintext*)>
<!ELEMENT plaintext (#PCDATA)>

<!ATTLIST plaintext
 style   ID #REQUIRED
>

XML:
<?xml version='1.0'?>
<?xml:stylesheet type = "text/xsl" href="created2.xsl"?>
<!DOCTYPE bireport SYSTEM "dtdsample.dtd">
<root>
<elements>
<label>
<plaintext style="labelprop">
Some Text 3.4567</plaintext>
</label>
</elements>
</root>


XSL:
.labelprop{top:0px;left:0px;width:152px;height:56px;font:arial;font-size:24pt;color:red;position:relative;}

<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> 
<xsl:template match="plaintext">  
<xsl:number value="$nmbr" format"2.000"/>
<xsl:value-of select="format-number($nmbr,"2.000")"/>
</xsl:template>  
</xsl:stylesheet>  

I want my html to look like:

Some Text 3.456  **note only 3 digits**

Thanks in advance.

Yogita Patil
Software Developer
Hummingbird Communications Ltd.
Decision Portals Division.
552 Princess Street.
Kingston, Ontario.
K7L-1C7
(613) 548-4355 Ext. 1540

Canada.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991115/3c4273af/attachment.htm
From simonstl at simonstl.com  Mon Nov 15 18:12:25 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:00 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <3.0.32.19991115095732.01337e50@pop.intergate.ca>
Message-ID: <199911151811.NAA17870@hesketh.net>

At 09:57 AM 11/15/99 -0800, Tim Bray wrote:
>Hmm.... just specify the use of a nonvalidating processor.  These have the 
>right to ignore external entities, not to barf, just to ignore them.  If
>the system is specified in this way, nobody will send external entities.
>(Which lord knows they shouldn't be doing in ecommerce-land anyhow).

Nope, sorry, not that easy, unless you specify the use of a specific
processor or put big warning labels throughout indicating that external
entities should not be used.  Otherwise, some brillant techie who built a
system on Aelfred or MSXML will start using external entities for things
like company identification headers and everyone else's systems will barf
when they find &mycompany; in place of <company
participant="z75006">....</company>.

Specifying the use of nonvalidating processors:
a) denies you the benefits of validation, if you actually cared
b) leaves you in a no-mans-land where external resources may or may not get
retrieved, leading to different folks taking advantage of different
toolsets and expecting them to work the same way when they don't.

I wish the spec had avoided b, but I'm afraid it didn't.  We're still stuck
in this problem.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 18:20:08 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:01 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: Sean Mc Grath's message of "Mon, 15 Nov 1999 17:35:48 +0000"
References: <3.0.6.32.19991115173548.009256d0@gpo.iol.ie>
Message-ID: <m33du7r52t.fsf@localhost.localdomain>

Sean Mc Grath <digitome@iol.ie> writes:

> I would argue they do get actively in the way.
> Sure, the EDI stuff probably does not need external parsed entities
> and who knows what else. But if EDI software is going to
> truthfully "use XML" and "be fully XML compliant" then it
> cannot just barf when these things appear in XML docs.

Whoa!  Let's imagine an engineer (let's say, the Desperate Palmtop
Hacker, or DPH for short) who's implementing XML support on a small
device.  She's probably not even *looking* at the XML 1.0 grammatical
productions; instead, she's choosing a library, possibly in Java with
a SAX interface, and getting at the XML through that.

Now, this engineer cares only about elements, attributes, and data --
she doesn't need to know anything about comments, notations, external
unparsed entities, processing instructions, whitespace in element
content, or a bunch of other stuff.  So, what extra work does she have 
to do with full XML vs. a subset?

a. She has to *not* provide a DTDHandler to the SAX parser.

b. She has to *not* override the processingInstruction and
   ignorableWhitespace callbacks from HandlerBase.

c. er, that's it.

So, obviously, implementation complexity is not a legitimate argument
for a creating a subset -- there are more than 20 XML parsing
libraries available in most major programming languages, and most of
those libraries of which provide event-based interfaces (where you can
ignore stuff by default), many are free, and some are very small.

Would the space savings from SML justify splitting the market with a
second markup language?  In my experience, no -- simply parsing
comments, CDATA sections, processing instructions, and even DTD
declarations adds almost nothing to the size of an XML parser.

When you're getting close to 10K, though (as I believe we could in
Java), the text of all the required XML 1.0 error messages may
actually become larger than the parser itself -- if you simply
replaced the text messages with numeric codes, you might save 5 to 10
times as much space as you would by cutting a few minor features.

To conform to XML 1.0, you also have to build some very, very large
tables so that you can detect the required errors for Unicode
characters not allowed in names, attribute values, character data,
etc., and the data required to build these tables might also add 25%
or more to the size of a very small XML parser.  I suggest that any
efforts at putting XML on small devices concentrate on this area
rather than tinkering with the admittedly slightly-pudgy (though not
bloated) XML grammer.


All the best,


David

p.s. If I could go back in time, I'd be happy to argue that notations, 
     unparsed entities, and some other junk be removed from XML 1.0,
     but it's too late now, and we won anyway.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at mitretek.org  Mon Nov 15 18:24:22 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:01 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <004e01bf2f96$9f3c6b00$38a3f1ce@ls-.mitretek.org>

Seems to me that there are several reasons to have commonality between XML and
WML, whether by SML or otherwise.
- Potential use of same tools (parsers, formatters, query engines, etc.).  Also
a larger  community developing them.
- A much larger pool of people who are familiar with working with the markup and
the tools (i.e., xml + wml have more developers than just wml alone).
- Much easier conversions between regular xml documents and documents designed
for wml-like uses.

Many people have noted that you can get most of "SML" by just not using various
XML features.  For wml-ish uses it would seem that there is a big need to handle
document fragments - another big topic here recently.  So when we get an xml
document fragment mechanism people are happy with, what's wrong with the wml
people standardising on an xml subset rather than a non-xml language?

Maybe the full xml document fragment mechanism would be too heavy-weight for
wml-ish applications, since there could be so much context information that
might be needed.  Then the wml standard could still be well-formed xml except
for the fragment wrapper.  This should still be relatively easy to handle for
wml-xml conversions.

So I'm saying that wml should become more closely overlapped with xml.

Tom Passin

From: Robert La Quey <robertl1@home.com>


<snip>
>>What I have in mind is a subset of XML, I'll call it Simple
>>(or Stupid) Markup Language (SML) for now, that simplifies XML
>>down to the bare essentials.  Ideally, it should also be a
>>subset of Canonical XML.  Here are some ideas:
>>
>>o No Attributes (ouch!)
>>o No PI, Comments, Notations, or CDATA sections
>>o No document type declaration
>>o UTF-8 encoding only
>>o No non-character entity references
>>o No predefined character entities (I am iffy on this one)
</snip>


>OK, enough lurking. I would like to pick this thread back up
>from the beginning and restart the discussion with a call for
>opinions from another crowd who seem (to me) conspicuously missing
>from the discussion. Are there any other lurkers in
>this group who have interest in the HDML->WML->XML=SML story?
>
>i.e. XML from the point of view of a very small systems (embedded)
>perspective. I think the SGML->XML crowd has pretty well stated
>their reasons for disliking SML. My own opinion is this. SML will
>happen (perhaps as WML, perhaps as many SMLs, a 1000 flowers bloom)
>as a de facto reality in arenas where fast product time to market
>and young engineers dominate the scene.
>
>As for lots of users. Ha! The largest cell phone community is already
>China with 25 Million users (UTF-8???). So the SML question they pose,
>while very different from the SGML world of woe and complexity, is perhaps
>of some importance.
>
>Is the overlap into the XML world worth pursuing or should the WML
>world just go its own way?
>
>Comments?
>
>Bob La Quey



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 18:33:19 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:01 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <3.0.32.19991115095732.01337e50@pop.intergate.ca>
Message-ID: <3.0.6.32.19991115181434.009c91d0@gpo.iol.ie>

[Tim Bray]
>>
>>I would argue they do get actively in the way.
>>Sure, the EDI stuff probably does not need external parsed entities
>>and who knows what else. But if EDI software is going to
>>truthfully "use XML" and "be fully XML compliant" then it
>>cannot just barf when these things appear in XML docs.
>
>Hmm.... just specify the use of a nonvalidating processor.  These have the 
>right to ignore external entities, not to barf, just to ignore them.  If
>the system is specified in this way, nobody will send external entities.
>(Which lord knows they shouldn't be doing in ecommerce-land anyhow).
>
>Next problem? -Tim
>
But ignoring the external entity references does not solve
the problem does it? The app won't work and given that the
XML stuff is going to be quite low down in the software layers,
these bugs will be hard to track down.

For "barf" in the above read "will not work for non-obvious reasons".

regards,




<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at mitretek.org  Mon Nov 15 18:41:45 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:01 2004
Subject: Profiling and Packaging XML
Message-ID: <005301bf2f99$04e9dbc0$38a3f1ce@ls-.mitretek.org>


From: Simon St.Laurent <simonstl@simonstl.com>


>It seems like everyone has their own list of favorite features in XML, as
>well as a list of features whose inclusion in XML they consider heretical.
>(The W3C, for instance, doesn't seem very happy about processing
>instructions, based on some statements in things like the style sheet PI
>Rec.)
>
>Since the SGML declaration was first against the wall (mostly an excellent
>thing), we don't have any way whatsoever to indicate that features are
>required, optional, or prohibited.  We don't even have a way to indicate
>that documents might, for instance, require validating parsers to avoid
>losing the 99.9% of their content that happens to reside in external
>resources.  (I've done a lot of work on this in XML Processing Description
>Language, XPDL, at http://purl.oclc.org/NET/xpdl, but figure my work will
>show up in some other project at best.)
>

>It sounds like the W3C is pondering XML packaging in round III of the XML
>Activity.  Might this be a good time to discuss what kinds of information
>we'd like to see in those packages?  Does profiling seem like a useful
>tool?  It seems like it might allow developers to specify rules like 'no
>external entities', 'no PIs', and 'no namespaces' for particular
>applications, and let us all have our opinions but not necessarily inflict
>them on everyone else's parsing.


One way to specify the presence or absence of optional features would be to
insert an element just after the root element that functions somewhat like the
xslt  <xsl:output> element.  An xslt processor determines what output format is
desired based on this element, which is optional.  Similarly, an xml processor
could look at a tag, perhaps <features-xml:required
external-unparsed-entities="no">, and learn what features are needed to process
the document.  There would be a namespace for features:xml, and a processor
would be free to disregard the features attributes.

It seems like a PI could also provide these services just as well.  Either way,
a processor that does not understand the instructions would just provide full
processing as usual.

Of course, there are lots of ways to accomplish the goal of specifying features
needed by a document.  The BIG question is, should such a mechanism become part
of the XML standard or not?  We have several precedents to look at.  Namespaces
and associating stylesheets were accomplished without adding them to the XML
standard itself.  I suggest that this is the way to go - have another small
standard for specifying optional features  This standard MAY be implemented by
xml processors.

>
>(I suspect that everyone will actually continue to use XML 1.0 parsers
>rather than write their own, but I don't think that reduces the need for
>documenting such profiles.)
>
>Phew!  A week away from XML-dev.  Lots of messages, almost all of them
>interesting.
>
>Simon St.Laurent
>XML: A Primer, 2nd Ed.
>Building XML Applications
>Inside XML DTDs: Scientific and Technical
>Sharing Bandwidth / Cookies
>http://www.simonstl.com
>

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 15 18:45:39 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:01 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <3.0.32.19991115104625.02033910@pop.intergate.ca>

At 01:11 PM 11/15/99 -0500, Simon St.Laurent wrote:
>At 09:57 AM 11/15/99 -0800, Tim Bray wrote:
>>Hmm.... just specify the use of a nonvalidating processor.  These have the 
>>right to ignore external entities, not to barf, just to ignore them.  
>
>Nope, sorry, not that easy, unless you ...
>put big warning labels throughout indicating that external
>entities should not be used.  

Right, that's it exactly.  Even if you happen to be using a processor
that might try to resolve them.  Sorry, I just don't see this as a big deal.

>Otherwise, some brillant techie who built a
>system on Aelfred or MSXML will start using external entities for things
>like company identification headers and everyone else's systems will barf
>when they find &mycompany; in place of <company
>participant="z75006">....</company>.

Doing this kind of thing might make excellent sense if you define
your entities in the internal subset.  Save bandwidth, potentially.

But anyone who uses external parsed entities in an e-commerce application
is just stupid.  Yes, the XML 1.0 spec would be greatly improved if there
were some syntactic signal in the XML declaration saying "I promise not
to reference any external entities".  

But in fact there are all sorts of really stupid things you can do in
XML (remember the billion laughs?) and the spec won't stop you.  Using 
external entities inappropriately is just one of them.

I repeat my claim; for EDI-style messaging, XML 1.0, used appropriately,
doesn't get in the way.  It also doesn't lead us auto-magically to the
next generation of ssssssssssssssssssseamless new-paradigm next-gen
e-everything.  But it doesn't get in the way, and claims that we need
to split XML into multiple incompatible versions as part of a solution
to this non-problem are just silly. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Curt.Arnold at hyprotech.com  Mon Nov 15 18:52:56 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:17:01 2004
Subject: International booleans proposal
Message-ID: <61DAD58E8F4ED211AC8400A0C9B468734154C8@THOR>

Hopefully this amounts to what Andrew Layman and Rick Jeliffe considers a
well-thought out alternative proposal.  I would appreciate any stones that
people could throw at it since I think it solves a lot of problems with
minimal additional functionality.

Basically, the idea is to add a few things to the enumeration and literal
elements to provide a minimum transform layer when extending datatypes.
Previous messages I've posted to the schema
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999JulSep/0053.
html and
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999JulSep/0029.
html were more ambitious.  This tries to get the essentials done for the
"international booleans" problems with the least amount of additional
functionality.

---------
Current version of datatypes

2.4.2.4 enumeration
[Definition:] Presence of an enumeration facet constrains the value space of
the datatype to the specified list. The enumeration facet can be applied to
to the following datatypes: string (?3.2.1), real (?3.2.3), timeInstant
(?3.2.4), timeDuration (?3.2.5), recurringInstant (?3.2.6), language
(?3.2.9), NMTOKEN (?3.3.1), Name (?3.3.3), NCName (?3.3.4), ENTITY (?3.3.8),
NOTATION (?3.3.10), decimal (?3.3.11), integer (?3.3.12),
non-negative-integer (?3.3.13), positive-integer (?3.3.14),
non-positive-integer (?3.3.15), negative-integer (?3.3.16), date (?3.3.17),
time (?3.3.18). No order or any other relationship is implied between the
elements of the enumeration list. 

New would have to be something like

[Definition:] Presence of an enumeration facet lists acceptible lexical
values for the datatype.  By default, an enumeration facet constrains the
lexical space to the enumerated values.

-------------

Example of enumerations

Currently:

<datatype name="holidays">   
   <basetype name="date"/>   
   <enumeration>   
      <literal>   
        --01-01    <!-- New Year's day -->   
      </literal>   
      <literal>   
        --07-04    <!-- 4th of July -->   
      </literal>   
      <literal>   
        --11-25    <!-- Thanksgiving -->   
      </literal>   
      <literal>   
        --12-25    <!-- Christmas -->   
      </literal>   
   </enumeration>   
</datatype>

Replace with (I've switched to fixed days in 2000, cause I have a
significant amount of issues with dates in the current draft covered in
different messages)

<datatype name="holidays">   
   <basetype name="date"/>   
   <enumeration>   
      <literal value="2000-01-01">
	NewYearsDay   
      </literal>   
      <literal value="2000-07-04">   
	FourthOfJuly
      </literal>   
      <literal value="2000-11-23">
	Thanksgiving   
      </literal>   
      <literal value="2000-12-25">
	Christmas   
      </literal>   
   </enumeration>   
</datatype>


----------------

Schema for datatypes:

Currently:

<element name='enumeration'> 
	<archetype>
		 <element ref='literal' minOccurs='1' maxOccurs='*'/> 
	</archetype> 
</element> 

<!-- the true datatype of the following depends on the basetype --> 
<element name='literal' type='string'/> 

Suggested replacement:

<element name='enumeration'> 
	<archetype>
		 <element ref='literal' minOccurs='1' maxOccurs='*'/> 
		<attribute name='model' type='NCName' default='closed'> 
			<enumeration> 
				<!--  lexical value may match one of the
enumerated values or 
					may be valid lexical value for base
type -->
				<literal>open</literal> 
				<!--  lexical value must match one of the
enumerated values  -->
				<literal>closed</literal> 
			</enumeration> 
		</attribute> 
	</archetype> 
</element> 

<!-- the true datatype of the following depends on the basetype --> 
<element name='literal' type='string'> 
	<archetype>
		<!-- if provided, the value is a representation of this
literal in the lexical space of the base type.
			if not provided, the content of the element is used
as the value -->
		<attribute name='value' type='string'/>
	</archetype>
</element>


--------------

Here is how this could be used for international booleans



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 19:02:13 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:01 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <3.0.32.19991115104625.02033910@pop.intergate.ca>
Message-ID: <199911151901.OAA20798@hesketh.net>

At 10:46 AM 11/15/99 -0800, Tim Bray wrote:
>>>Hmm.... just specify the use of a nonvalidating processor.  These have the 
>>>right to ignore external entities, not to barf, just to ignore them.  
>>
>>Nope, sorry, not that easy, unless you ...
>>put big warning labels throughout indicating that external
>>entities should not be used.  
>
>Right, that's it exactly.  Even if you happen to be using a processor
>that might try to resolve them.  Sorry, I just don't see this as a big deal.

Try explaining this glitch to people who don't understand XML well enough
to understand what an 'external entity' is a few hundred times, and perhaps
your opinion of its importance will change.  The guy who used '&mycompany;'
may know what it means, but the lucky troubleshooter on the other end may
well not know - and probably shouldn't have to know.

We're probably stuck with the mess, but unfortunately it's a very big deal
to certain classes of users, particularly those who'd like XML application
to process XML documents without a lot of oversight about 'what XML really
is'.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Curt.Arnold at hyprotech.com  Mon Nov 15 19:03:50 1999
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:17:01 2004
Subject: International booleans proposal (con't)
Message-ID: <61DAD58E8F4ED211AC8400A0C9B468734154C9@THOR>

Oops, pressed wrong key which prematurely send last message.  To follow

Examples of use:

Swedish-only boolean 

<datatype name="swedishOnlyBoolean">
	<basetype name="boolean"/>
	<enumeration>
		<literal value="true">sant</literal>
		<literal value="false">falskt</literal>
	</enumeration>
</datatype>

--------------

Swedish and default boolean.  Accepts true and false in additional to
explicitly enumerated values since enumeration is open and true and false
are legal values for base type.

<datatype name="swedishSupportingBoolean">
	<basetype name="boolean"/>
	<enumeration model="open">
		<literal value="true">sant</literal>
		<literal value="false">falskt</literal>
	</enumeration>
</datatype>


--------------------------

Swedish, default, and 0/1 boolean

<datatype name="multiBoolean">
	<basetype name="boolean"/>
	<enumeration model="open">
		<literal value="true">sant</literal>
		<literal value="false">falskt</literal>
		<literal value="true">1</literal>
		<literal value="false">0</literal>
	</enumeration>
</datatype>

-----------------------

Numeric data type with symbolic names

<datatype name="symReal">
	<basetype name="real"/>
	<enumeration model="open">
		<literal value="3.1415926">pi</literal>
		<literal value="2.718">e</literal>
	</enumeration>
</datatype>

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



From tpassin at mitretek.org  Mon Nov 15 20:39:09 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:01 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <005c01bf2fa9$61ca7560$38a3f1ce@ls-.mitretek.org>

The latest posts in this thread seem to be talking mainly about external parsed
entities and what subset to use, with a few choice goodies of like nature.  Most
of these issues aren't really limited to the hypothetical users of some "SML".
External parsed entities, for example.  A really inexperienced xml user won't
even know they could be available or what they are good for.  A slightly more
experienced user might try using them.  Then their recipients have all the
problems people have been discussing - it has nothing to do with any small
subset of xml.

On the other hand, people designing message formats for portable phones, etc.,
had better be using some kind of standard, otherwise how do they know if the
other end can understand their messages?  And that standard could surely be an
xml subset with some wrappers or xml-compatible conventions.

So, for SML,  we are really talking some other users who want to "go Lite".  One
of the main issues is robustness - can we keep working even if everything in the
message isn't perfect according to us?  One example that was mentioned recently
is a leading blank line or space in a document.  Some processors barf, others do
ok.  Robustness is one of the things I like about xml - not that is is super
robust but it's quite a bit better than SGML is (speaking as an SGML-impaired
soul, no offense meant), and it's easier to ensure that the elements, etc., are
well-formed.  Having your non-validating parser keep going when there is
something it doesn't know about is robustness, for example.

It seems, then, that the main users who would be interested in some kind of SML,
according to what I've been seeing in this thread, are 1) those who want to dive
into xml and not bother with many of the fine points in the standard, and 2)
those who need a small footprint (or small message size).  These groups do NOT
have the same interests, and probably one "SML" won't work for both of them. For
each of these groups, I think that David Megginson's post on 11/15 is right on
target.  Let's focus on how the footprint can be reduced (i.e., smaller error
message tables, etc.), and on how to increase robustness for document fragments,
etc.

Tom Passin

From: Simon St.Laurent <simonstl@simonstl.com>


>At 10:46 AM 11/15/99 -0800, Tim Bray wrote:
>>>>Hmm.... just specify the use of a nonvalidating processor.  These have the
>>>>right to ignore external entities, not to barf, just to ignore them.
>>>
>>>Nope, sorry, not that easy, unless you ...
>>>put big warning labels throughout indicating that external
>>>entities should not be used.
>>
>>Right, that's it exactly.  Even if you happen to be using a processor
>>that might try to resolve them.  Sorry, I just don't see this as a big deal.
>
>Try explaining this glitch to people who don't understand XML well enough
>to understand what an 'external entity' is a few hundred times, and perhaps
>your opinion of its importance will change.  The guy who used '&mycompany;'
>may know what it means, but the lucky troubleshooter on the other end may
>well not know - and probably shouldn't have to know.
>
>We're probably stuck with the mess, but unfortunately it's a very big deal
>to certain classes of users, particularly those who'd like XML application
>to process XML documents without a lot of oversight about 'what XML really
>is'.
>
>Simon St.Laurent



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



From bhurt at talkware.net  Mon Nov 15 20:53:50 1999
From: bhurt at talkware.net (Brian Hurt)
Date: Mon Jun  7 17:17:02 2004
Subject: expat as a shared library
Message-ID: <Pine.LNX.4.10.10811230234270.1188-100000@mars.talkware.net>

I'm looking at building expat as a shared library (.so) on linux, to make
it easier to build into programs.  Searching the archives reveals only one
message, from James Thompson, back in july, and no replies.

Some questions:
1) Is there any reason people are opposed to this?
2) Mr. Thompson ran into problems in July- have they been resolved?
3) What is the approved method for submitting patches to expat?  Just post
them to the list?  Send them to James Clark?  Is there a cvs or ftp
repository they should be going in?

Thanks for you help.
Brian



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 21:08:59 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991113113706.01335d90@pop.intergate.ca>
Message-ID: <3830765B.2AF57599@pacbell.net>

Tim Bray wrote:
> > 
> The UTF-*'s are logically equivalent to most users, in that they share
> the property that almost no real-world data objects are encoded in either.

Quite true, from what I know, if you don't consider all the documents
encoded in ASCII (which is a subset of UTF-8).  Many of them aren't
tagged as to encoding; assert they're UTF-8 not ASCII, and disproof is
often going to be impossible!

Worth noting however is that the IETF recognized a policy last year to push
the use of UTF-8 in new protocols.  Other registered encodings are fine,
but UTF-8 support is mandatory.  See http://www.ietf.org/rfc/rfc2277.txt
for a few more details; it's "best current practices" on the Internet.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov 15 21:38:28 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca>
Message-ID: <00bf01bf2fb0$9e87c230$e5bdb3c7@PTGRESTON>


----- Original Message -----
From: Tim Bray <tbray@textuality.com>
To: Michael Champion <Mike.Champion@softwareag-usa.com>; <xml-dev@ic.ac.uk>
Sent: Monday, November 15, 1999 12:23 PM
Subject: Re: Feeler for SML (Simple Markup Language)


> So what do you recommend?  Specifically please.

1 - I'd like to see an activity not unlike the one that defined SAX a couple
of years ago collaboratively researching what a minimal subset of XML and/or
the DOM  for high-performance and/or small footprint processors might look
like.  This would entail some actual code experiments to see if there really
is a significant decrease in processing time or code footprint by throwing
out support for these features.  If there's no empirically demonstratable
gain, I for one don't want to continue the pain of this discussion.

2 - Assuming for the moment that a gain can be demonstrated, I'd like to see
a mechanism in XML itself to allow XML messages, documents, etc. to specify
that they use only some defined subset of features. In other words, I'd like
to see some built-in mechanism for "bifurcating" XML without descending into
the chaos of non-interoperability.

3 - I'd like to see some specification or demonstration for how an XML
processor that is optimized for a subset of the spec can "barf" on external
entities or other unsupported features in a way that would allow it to
potentially extract useful information out of the document or message it's
processing.  For example, I might (for some reasons of my own) document or
"decorate" an XML message with attributes or entities, but when Don Park
gets it ;~) , his stripped down processor should be able to extract the
"wheat" (simple element values) and ignore the "chaff" (my documentation and
decoration). Such a mechanism would have to be much lighter weight than what
would be possible with DTDs or schemas.
(Again, if it can be demonstrated that something functionally equivalent can
be done *efficiently* without mucking with the XML spec, so much the
better).









xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 15 22:02:09 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <3.0.32.19991115140044.013c4790@pop.intergate.ca>

At 01:08 PM 11/15/99 -0800, David Brownell wrote:
>> The UTF-*'s are logically equivalent to most users, in that they share
>> the property that almost no real-world data objects are encoded in either.
>
>Quite true, from what I know, if you don't consider all the documents
>encoded in ASCII (which is a subset of UTF-8).  Many of them aren't
>tagged as to encoding; assert they're UTF-8 not ASCII, and disproof is
>often going to be impossible!

I used to think so too, but actually, if you look closely, the proportion
of "ascii" that's actually pure US-ASCII is not that high.  The prevalence
of ?'s and ?'s and so on these days is in my experience really growing,
which means that documents which are ideally ISO-8859-1 but in fact
some Microsoft codepage is really immense.  -T.

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



From Steve.Ball at zveno.com  Mon Nov 15 22:35:10 1999
From: Steve.Ball at zveno.com (Steve Ball)
Date: Mon Jun  7 17:17:02 2004
Subject: expat as a shared library
References: <Pine.LNX.4.10.10811230234270.1188-100000@mars.talkware.net>
Message-ID: <38308ACF.4910E0F7@zveno.com>

Brian Hurt wrote:
> 
> I'm looking at building expat as a shared library (.so) on linux, to make
> it easier to build into programs.  Searching the archives reveals only one
> message, from James Thompson, back in july, and no replies.
> 
> Some questions:
> 1) Is there any reason people are opposed to this?
> 2) Mr. Thompson ran into problems in July- have they been resolved?
> 3) What is the approved method for submitting patches to expat?  Just post
> them to the list?  Send them to James Clark?  Is there a cvs or ftp
> repository they should be going in?

TclExpat - the Tcl interface to expat - builds expat as a shared library.
That's the easiest way to load the package into a Tcl interpreter.

Building a shared library is quite easy.  TclExpat builds expat in the
usual way, but adds the -PIC flag.  It then takes the object files and
constructs the shared library.  The know-how on how to do that on various
platforms is actually taken from the Tcl configuration, since Tcl is
very good at determining which compile and link flags are ncessary.
I can dig up some more specific details if you require.

I don't the answer to (3), but I think sending them to JC is the way to go.

HTHs,
Steve Ball

-- 
Steve Ball            |   Swish XML Editor    | Training & Seminars
Zveno Pty Ltd         |   Web Tcl Complete    |      XML XSL
http://www.zveno.com/ |    TclXML TclDOM      | Tcl, Web Development
Steve.Ball@zveno.com  +-----------------------+---------------------
Ph. +61 2 6242 4099   | Mobile (0413) 594 462 | Fax +61 2 6242 4099

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



From bhurt at talkware.net  Mon Nov 15 22:47:36 1999
From: bhurt at talkware.net (Brian Hurt)
Date: Mon Jun  7 17:17:02 2004
Subject: expat as a shared library
In-Reply-To: <38308ACF.4910E0F7@zveno.com>
Message-ID: <Pine.LNX.4.10.10811230425340.1188-100000@mars.talkware.net>



On Tue, 16 Nov 1999, Steve Ball wrote:

> Brian Hurt wrote:
> > 
> > I'm looking at building expat as a shared library (.so) on linux
> 
> Building a shared library is quite easy.  TclExpat builds expat in the
> usual way, but adds the -PIC flag.  It then takes the object files and
> constructs the shared library.  The know-how on how to do that on various
> platforms is actually taken from the Tcl configuration, since Tcl is
> very good at determining which compile and link flags are ncessary.
> I can dig up some more specific details if you require.

Oh, how to do it was easy (see diff file at the end of this message).  I
was more wondering if this ground had been covered before and I was just
missing it.

Here's the diff.  It's short, so I hope I don't offend people by posting
it.  I haven't actually linked the output to anything yet, and you need to
put LDFLAGS=-shared on the make command line.  But I poked through the
resultant .so and things look good.

Index: Makefile
===================================================================
RCS file: /UTC1/cvsroot/utc/clib/expat/Makefile,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Makefile	1999/11/15 20:23:31	1.1
+++ Makefile	1999/11/15 22:30:20	1.2
@@ -16,6 +16,10 @@
   xmlparse/xmlparse.o \
   xmlparse/hashtable.o \
   $(FILEMAP_OBJ)
+LOBJS=xmltok/xmltok.o \
+  xmltok/xmlrole.o \
+  xmlparse/xmlparse.o \
+  xmlparse/hashtable.o
 EXE=
 
 all: xmlwf/xmlwf$(EXE)
@@ -23,8 +27,16 @@
 xmlwf/xmlwf$(EXE): $(OBJS)
 	$(CC) $(CFLAGS) -o $@ $(OBJS)
 
+libexpat.so: $(LOBJS)
+	$(LD) $(LDFLAGS) -o $@ $(LOBJS)
+
+linuxinstall:
+	install -m 644 -g 0 -o 0 libexpat.so /usr/lib
+	install -m 644 -g 0 -o 0 xmltok/xmltok.h /usr/include
+	install -m 644 -g 0 -o 0 xmlparse/xmlparse.h /usr/include
+
 clean:
-	rm -f $(OBJS) xmlwf/xmlwf$(EXE)
+	rm -f $(OBJS) xmlwf/xmlwf$(EXE) libexpat.so
 
 xmltok/nametab.h: gennmtab/gennmtab$(EXE)
 	rm -f $@


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



From jamesr at steptwo.com.au  Mon Nov 15 22:53:53 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <383048C2.AFABE24F@praxis.cz>
References: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca>
Message-ID: <4.2.0.58.19991116094724.00cda1f0@203.41.126.17>

At 04:54 16/11/1999 , Matthew Gertner wrote:
>Tim Bray wrote:
> > As for the WML world, the WAP-folk have apparently taken the decision that
> > none of IP/HTTP/HTML/XML are appropriate for them without significant 
> rework.
> > Anyone is free to disagree, but they're the ones building the cellphones.
>
>Did I miss something? I have the June 99 WML draft sitting on my desk,
>and while I haven't checked every detail, it looks pretty close to a
>conformant XML app. There might be some problems with character encoding
>and the XML declaration (or lack thereof), but I would hardly call this
>"significant rework".

There's the unique binary compression method
for a start. From what I've read, this is badly
spec'd enough to mean that the few implementations
so far are incompatible. Sigh.

Anyway, it's the lack of use of TCP/IP/HTTP and HTML
that is the big issue.

J


-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
http://www.steptwo.com.au/
jamesr@steptwo.com.au

"Beyond the Idea"
  ACN 081 019 623

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



From Cem.Redif at Xpedior.com  Mon Nov 15 22:55:21 1999
From: Cem.Redif at Xpedior.com (Cem Redif)
Date: Mon Jun  7 17:17:02 2004
Subject: (no subject)
Message-ID: <38308F2C.1BDB2E2A@Xpedior.com>

unsubscribe


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 22:58:17 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991115140044.013c4790@pop.intergate.ca>
Message-ID: <38308FEC.9F28C1B5@pacbell.net>

Tim Bray wrote:
> 
> At 01:08 PM 11/15/99 -0800, David Brownell wrote:
> >> The UTF-*'s are logically equivalent to most users, in that they share
> >> the property that almost no real-world data objects are encoded in either.
> >
> >Quite true, from what I know, if you don't consider all the documents
> >encoded in ASCII (which is a subset of UTF-8).  Many of them aren't
> >tagged as to encoding; assert they're UTF-8 not ASCII, and disproof is
> >often going to be impossible!
> 
> I used to think so too, but actually, if you look closely, the proportion
> of "ascii" that's actually pure US-ASCII is not that high. 

Well, ASCII is ASCII -- if it's not pure, it's not ASCII (and
hence it's not usable as UTF-8 either).  ASCII uses only seven
bits; always has (modulo parity), and I can't see that changing.

But while that's key to what I was saying (if it _really_ is
ASCII, it's also UTF-8, and there's lots of real ASCII), I
suspect that was likely not what you were getting at there.


>	 The prevalence
> of ?'s and ?'s and so on these days is in my experience really growing,
> which means that documents which are ideally ISO-8859-1 but in fact
> some Microsoft codepage is really immense.  -T.

Those characters are actually in ISO-8859-1, but I understand that
Microsoft does cause real problems by its use of many characters
that are reserved in 8859-1 ... look at the number of web pages
with strange characters where you should have &ldquo; or &rdquo;
(but hmm, not all browsers accept those entities anyway).

Assert that one of those documents is ASCII, and disproof is trivial:
some character has the eighth bit set.  (When was the last time you
saw a document using it for parity?  A LONG time ago, for me!)  Since
it's not ASCII, you clearly can't read it as UTF-8.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 15 23:14:29 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:02 2004
Subject: XML and SML
References: <A51F7543E295D2118D6600A024CDB2F71B9CC4@MAILPROD>
Message-ID: <383093CB.570E4ABA@pacbell.net>

OFFTOPIC but illustrative:

Vane Lashua wrote:
> 
> There is computer power galore to implement full-blown SGML, XML, HTTP, a
> browser and Unix in a toaster today. Would it (the computer power) even cost
> $50? Would it even take 6 months to get it accomplished?

Today's digital cameras are powerful enough to run arcade games
of not all that long ago.  My toaster works fine using my existing
ten digits, doesn't need more, but for devices which truly need
a processor this link should illustrate some of the (presumably :-)
unintended consequences:

    http://members.aol.com/JWSurine/

Now tell me, seriously, that if such a camera can run PacMan it
doesn't have enough horsepower to run a basic XML/HTTP client
and render a UI that doesn't depend on a huge display. 

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 06:57:02 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <002c01bf2f8f$4fc48050$e5bdb3c7@PTGRESTON>
Message-ID: <Pine.GSU.4.10.9911152241280.24665-100000@netcom10.netcom.com>

On Mon, 15 Nov 1999, Michael Champion wrote:
> Remember 1995-1997 in the HTML Web ... It saw HTML become its own "world"
> totally distinct from its SGML roots, and it saw numerous incompatible
> variants of HTML proliferate. This could happen again, this time with XML as
> the creaky old "bloated" standard that doesn't fit the needs of the
> fast-moving innovators.  I'm not at all sure that "SML" could prevent that,
> but I see the same complaints about XML and the DOM API (pretty much the
> points that Don made in the original post) again and again among people
> trying to use it in light client or high performance applications.

But the HTML scenario is exactly the opposite of the potential WML
scenario in that the browser manufacturers were creating incompatible
*supersets* of a particular markup language, incompatible not only with
each other but also with the basic framework (SGML) the language was
defined with.  The latter incompatibility was partially the result of SGML
parsers being complex beasts, but even more so because many of the
implementors either didn't know what structural markup was or, as in the
case of Mark Andreesen, knew what it was but were philosophically opposed
to it.  In the wireless scenario, though, the worst case is devices having
parsers that can handle only the particular XML constructs used by the
specific markup languages initially created for those devices; IOW, a
proliferation of non-extensible markup languages.  That's nowhere near as
bad.

I've gotten somewhat miffed at the number of people who seem to think that
the DOM is *the* One and Only True Way to access XML documents, and I'm
pretty certain that that particular meme originated in Redmond;
Microsoft's parsers indeed provide nothing else.  Yes, the DOM is too
heavyweight for lots of applications, but we *already* have lighter-weight
APIs; it's just a question of making developers aware of them.  Let's not
try stripping down the *language* in a misguided attempt to deal with the
complexity of a particular *API*.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 07:20:42 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <199911151901.OAA20798@hesketh.net>
Message-ID: <Pine.GSU.4.10.9911152305030.24665-100000@netcom10.netcom.com>

On Mon, 15 Nov 1999, Simon St.Laurent wrote:

> At 10:46 AM 11/15/99 -0800, Tim Bray wrote:
> >Right, that's it exactly.  Even if you happen to be using a processor
> >that might try to resolve them.  Sorry, I just don't see this as a big deal.
> 
> Try explaining this glitch to people who don't understand XML well enough
> to understand what an 'external entity' is a few hundred times, and perhaps
> your opinion of its importance will change.  The guy who used '&mycompany;'
> may know what it means, but the lucky troubleshooter on the other end may
> well not know - and probably shouldn't have to know.
> 
> We're probably stuck with the mess, but unfortunately it's a very big deal
> to certain classes of users, particularly those who'd like XML application
> to process XML documents without a lot of oversight about 'what XML really
> is'.

Whoa there!  This is starting to remind me of some of the flamewars on
comp.lang.perl.misc over whether it's reasonable to expect a programmer to
RTFM!  If a particular wireless protocol really does need to be usable by
script kiddies [1], then the solution, to the extent that one is possible,
is to hide all the details in an application-specific API.  If someone
doesn't want to understand what XML is, to the extent of knowing what an
external entity is, they should *not* be using an API that's expressed in
terms of XML constructs!  If the protocol can't handle external
entitities, yet needs to be usable by Web Slaves who wouldn't know a
markup language from a hole in the ground, then you need an API whose
implementation isn't capable of generating external entity references.
It's that simple.

[1] A script kiddie is someone who writes (or more likely cuts and pastes)
code without having, or desiring to have, a mental model of what the code
does; someone who thinks of code as magical incantations and asks "what do
I need to type to make this happen."  Script kiddies are to programming as
prooftexters are to theology.



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



From matthew at praxis.cz  Tue Nov 16 09:58:59 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:02 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca> <00bf01bf2fb0$9e87c230$e5bdb3c7@PTGRESTON>
Message-ID: <38312A96.95E2E605@praxis.cz>

Michael Champion wrote:
> 1 - I'd like to see an activity not unlike the one that defined SAX a couple
> of years ago collaboratively researching what a minimal subset of XML and/or
> the DOM  for high-performance and/or small footprint processors might look
> like.  This would entail some actual code experiments to see if there really
> is a significant decrease in processing time or code footprint by throwing
> out support for these features.  If there's no empirically demonstratable
> gain, I for one don't want to continue the pain of this discussion.

I guess there's no harm in looking into this, but this seems like a road
to nowhere to me. On the one hand, it implies a serious risk of
unnecessary confusion because the differences between XML and the
putative SML will be too subtle for non-XML freaks to grog. On the other
hand, any compromise that is found is going to lead to inevitable
satisfaction, with some people feeling that too much was eliminated
while others feel that too much was left in.

> 2 - Assuming for the moment that a gain can be demonstrated, I'd like to see
> a mechanism in XML itself to allow XML messages, documents, etc. to specify
> that they use only some defined subset of features. In other words, I'd like
> to see some built-in mechanism for "bifurcating" XML without descending into
> the chaos of non-interoperability.

This is starting to sound like a pretty good idea. I imagine something
like the SGML declaration but specific to a given schema, rather than a
specific instance. This would enable a schema developer to say, for
example, that PIs, external parsed entities (or my preferences, any
entities), attributes, etc. are not usable with the schema in question.
This is something that the schema WG could add to the current spec with
very little effort. Simon posted something about having done some work
in this direction, but I can't connect to his site right now. In any
case, I'll happily write a short proposal if no one else wants to; it
should only be about an hour's work.

> 3 - I'd like to see some specification or demonstration for how an XML
> processor that is optimized for a subset of the spec can "barf" on external
> entities or other unsupported features in a way that would allow it to
> potentially extract useful information out of the document or message it's
> processing.  For example, I might (for some reasons of my own) document or
> "decorate" an XML message with attributes or entities, but when Don Park
> gets it ;~) , his stripped down processor should be able to extract the
> "wheat" (simple element values) and ignore the "chaff" (my documentation and
> decoration). Such a mechanism would have to be much lighter weight than what
> would be possible with DTDs or schemas.
> (Again, if it can be demonstrated that something functionally equivalent can
> be done *efficiently* without mucking with the XML spec, so much the
> better).

And alternative that is certainly worth considering: the processor
simply rejects the document if an unsupported feature is used. Since the
document authors are presumable writing (or the software developers
generating) an XML instance on the basis of a schema, the onus should be
on them to respect *all* aspects of the schema definition, including
supported features. The best thing a processing app can do is reject the
document out of hand, letting authors know that their implementation is
faulty and forcing them to fix it immediately before non-conformant
documents are unleased to wreck havoc. Your approach runs the risk of
producing behavior that was not expected and might therefore have
undesirable side-effects (considering the implications for e-commerce,
among other things).

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 10:08:53 1999
From: ssahuc at imediation.com (Sebastien Sahuc)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <C10B7E3A3AC3D211804E0000B45EDA8435CB9F@mail.imediation.com>

> > Try explaining this glitch to people who don't understand 
> XML well enough
> > to understand what an 'external entity' is a few hundred 
> times...

Well... the discussion must has been tackled several times in the
list, but I would like to have a summary of WHEN and WHEN NOT to use
external entities.

I sum up some points I have understood so far :

* DO NOT use external entities when working with remote XML document
since it would badly increase downloading time.

* DO use them only when you can rely on the parser's behaviour, i.e.
you know exactly how the parser will behave with these entities.

Any comments on this ?

Sebastien

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 10:38:19 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeling good about SML
Message-ID: <000001bf301e$f93c6460$099918d1@docuverse1>

Everyone,

Based on the responses to my first message titled "Feeler for SML",
I can make following conclusions:

Whether SML is the voice of reason or treason, it struck a cord in
the mind of many of us.  Whether the need for SML is illusional or
practical, it merits further investigations and thus require
investment in terms of time and efforts.  By time and effort, I
include the patience and continued vigilence of those XML-DEV
subscribers who disagree with the SML idea.

It is apparent that SML is not a new idea, there were similar efforts
made before and, if we do not come to a consensus this time, I am sure
we will see it resurface again and again until the need becomes
critical enough or we find something else to get obsessed about.
Let us make sure we give it a good effort this time around because,
frankly, I got no time for regrets.

To this end, I think we should now move to discussion on how we might
proceed.  One suggestion I have is that we should keep this discussion
within XML-DEV as long as possible.  The reason is that the amount
of readily available expertise in XML-DEV is simply staggering and I
believe we will benefit from it as we progress.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 10:47:25 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:03 2004
Subject: External Entities A Field Guide (was RE: Feeler for SML (Simple Markup Language))
In-Reply-To: <C10B7E3A3AC3D211804E0000B45EDA8435CB9F@mail.imediation.com>
Message-ID: <000d01bf301f$d2c357c0$ab20268a@pc-lrd.bath.ac.uk>

> but I would like to have a summary of WHEN and WHEN NOT to use
> external entities.
> 
> I sum up some points I have understood so far :
> 
> * DO NOT use external entities when working with remote XML document
> since it would badly increase downloading time.
> 
> * DO use them only when you can rely on the parser's behaviour, i.e.
> you know exactly how the parser will behave with these entities.
> 
> Any comments on this ?

Heres some others, gleaned from the discussions:

"The *ONLY TIME* external parsed entities are the right thing to do is
when exactly one actor is working on exactly one doucment and needs to
partition it into separate files for *their own* convenience. *AT ALL
OTHER TIMES* external parsed entities are not the right thing to use."
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0238.html

Use them to separate the logical and physical document structure
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0203.html
(first paragraph)

Never rely on data being stored in a specific entity
(above link, last paragraph, see also 
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0204.html)

I'm sure there are other wise words to be added as well!

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 11:42:08 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <199911151811.NAA17870@hesketh.net>
Message-ID: <000e01bf3027$75ea2440$ab20268a@pc-lrd.bath.ac.uk>

> >right to ignore external entities, not to barf, just to ignore them.  If
> >the system is specified in this way, nobody will send external entities.
> >(Which lord knows they shouldn't be doing in ecommerce-land anyhow).
> 
> Nope, sorry, not that easy, unless you specify the use of a specific
> processor or put big warning labels throughout indicating that external
> entities should not be used.  

Aren't those "big warning labels" going to be the schema/DTD/messaging 
format defined for your EDI/E-Commerce application. If you're 
in violation of that format then you message/data/whatever deserves 
to be junked. 

If you use entities internally thats fine, so long as they get 
replaced before the XML 'hits the wire'.

The problem applies equally to say, malformed element names - if 
its outside the spec it invalid.

I can see why perhaps there would be a need to gracefully recover 
from such cases, and attempt to get *something* out of the document, 
but if we're talking EDI/E-Commerce then we're probably talking 
atomic transactions as well, so getting *some* of the data 
just isn't enough.

If you've defined a standard messaging format that stops a lot 
of features being used, then I can also see some advantage in 
not having a parser which supports those features, if theres 
a significant performance/overhead difference, and I know 
the format is never going to be revised to add in any 
other those features.

So, conform to your spec and you'll be fine. It means that 
you may have to do additional work to ensure that the 
fragments/documents/messages don't use any illegal features, especially 
if you're handling fragments from outside your own domain.

I think you've already correctly pointed out (in your Packaging/Profiling 
posting) that this type of validation needs some attention.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 12:02:32 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeling good about SML
In-Reply-To: <000001bf301e$f93c6460$099918d1@docuverse1>
Message-ID: <001001bf302a$50d41820$ab20268a@pc-lrd.bath.ac.uk>

> To this end, I think we should now move to discussion on how we might
> proceed.  One suggestion I have is that we should keep this discussion
> within XML-DEV as long as possible.  The reason is that the amount
> of readily available expertise in XML-DEV is simply staggering and I
> believe we will benefit from it as we progress.

I'd say that looking to specify what features of the XML spec a 
schema uses would be the best place to start. As has already been 
pointed out, this can be a separate body of work and not 
require an amendment to the standard itself.

An XML parser then must still support the XML 1.0 spec. It 
may also optionally support this additional layer. An SML 
processor must support the additional layer at least, and 
as much of the XML 1.0 spec as it needs as it can hide 
behind this layer.

Being able to define a feature subset is going to be a requirement 
in the long-run anyway - because SML and XML will have to 
inter-operate. SML->XML processor is trivial. XML->SML processor 
is not. So the SML processor needs programmatic access to 
a definition of the feature subset in use to properly validate/handle
the XML document/fragment.

Once that is in place, you can 'hide' behind it to an 
extent and start stripping stuff from your parser, if 
necessary, because you can define your message format schema 
to only use those features you want.

That any use as a starter for 10?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 16 12:06:22 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeling good about SML
In-Reply-To: <000001bf301e$f93c6460$099918d1@docuverse1>
Message-ID: <3.0.6.32.19991116115426.0092c690@gpo.iol.ie>

[Don Park on SML]
>
>To this end, I think we should now move to discussion on how we might
>proceed.  One suggestion I have is that we should keep this discussion
>within XML-DEV as long as possible.  The reason is that the amount
>of readily available expertise in XML-DEV is simply staggering and I
>believe we will benefit from it as we progress.
>

I think there is a step before SML which -- if it went well --
might even remove the need for SML:

1) Tie down what the bifurcation areas that cause XML
interoperability problems and allow people to throw
the phrase "XML parser" around with wild abandon.
e.g. external subset processing, external entity references,
Unicode encoding(s) supported, location information, etc. etc.

For arguments sake, lets call this the XML Feature Manifest
(XMF).

2) Tie down a syntax -- presumably canonical XML -- to
store XFM.

3) XML parser writers would be encouraged to provide
an XFM so that humans and programs alike can determine
what the parser does and does not support.

4) XML Document Creators would be encouraged to
tack an XFM onto their document collections so
that humans and programs alike can determine
what XML features the document-set requires.

I see this as nothing more than codifying existing
practice. There are lots of parsers that claim
to be XML parsers but when you look closely they
don't do X,Y and Z per the specification.

I am as guilty as anyone of saying things
like "Python has N XML parsers" and "my app. is
fully XML compliant" when in reality there are
well defined areas of doubt and uncertainty in
those seemingly definitive statements.

I don't know to what extent this overlaps
with Simon St. Laurent because I cannot
connect to his site right now. Sorry.

Anyway, there is nothing new in the world.
What we have here is the "SGML Declaration"
concept revisited but on a much smaller
scale.

regards,



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



From gtn at ebt.com  Tue Nov 16 13:28:41 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <3.0.32.19991115095732.01337e50@pop.intergate.ca>
Message-ID: <000001bf3036$0571bb10$327370c6@eps.inso.com>

>>I would argue they do get actively in the way.
>>Sure, the EDI stuff probably does not need external parsed entities
>>and who knows what else. But if EDI software is going to
>>truthfully "use XML" and "be fully XML compliant" then it
>>cannot just barf when these things appear in XML docs.
>
> Hmm.... just specify the use of a nonvalidating processor.
> These have the right to ignore external entities, not to barf, just to
> ignore them.  If the system is specified in this way, nobody will send
> external entities.

I think the last point is extremely important. While you can complain
about XML features that "complicate" XML processing, at the end of the
day, XML isn't the thing that defines interoperability at the
application level.

For example, in EDI, you have to define vocabularies/scheme to be used.
If something sends you something outside defined schema, you're hosed.
In any interoperable system, there are a number of explicit or implicit
contracts tying all involved parties together. If anyone violates the
contracts, something fails.

So, for XML, the point is that if *in your application domain* you don't
like/want to use a feature, then you don't have to. You can even build
applications tailored for your specific usage of XML, and given that you
always feed it content in the agreed upon format, you would be unable to
tell if it was a full XML system, or a subset, because by definition,
full XML is able to handle the subset. In such cases, feeding it something
outside the application domain violates a validity contract made between
applications, and so it is fine for failure to occur... about the worste
that can happen is that the error message might not be meaningful.

Still, at the end of the day, I can't see that having an
application-specific
subset parser buys a whole lot. So I'd say to embed a full parser, but
limit, through external contract, what will be fed to it.



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



From wperry at fiduciary.com  Tue Nov 16 13:12:49 1999
From: wperry at fiduciary.com (W. E. Perry)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca> <00bf01bf2fb0$9e87c230$e5bdb3c7@PTGRESTON> <38312A96.95E2E605@praxis.cz>
Message-ID: <38315844.96455398@fiduciary.com>

Matthew Gertner wrote:

> Michael Champion wrote:
> > 3 - I'd like to see some specification or demonstration for how an XML
> > processor that is optimized for a subset of the spec can "barf" on external
> > entities or other unsupported features in a way that would allow it to
> > potentially extract useful information out of the document or message it's
> > processing.  For example, I might (for some reasons of my own) document or
> > "decorate" an XML message with attributes or entities, but when Don Park
> > gets it ;~) , his stripped down processor should be able to extract the
> > "wheat" (simple element values) and ignore the "chaff" (my documentation and
> > decoration). Such a mechanism would have to be much lighter weight than what
> > would be possible with DTDs or schemas.
> > (Again, if it can be demonstrated that something functionally equivalent can
> > be done *efficiently* without mucking with the XML spec, so much the
> > better).
>
> And alternative that is certainly worth considering: the processor
> simply rejects the document if an unsupported feature is used. Since the
> document authors are presumable writing (or the software developers
> generating) an XML instance on the basis of a schema, the onus should be
> on them to respect *all* aspects of the schema definition, including
> supported features. The best thing a processing app can do is reject the
> document out of hand, letting authors know that their implementation is
> faulty and forcing them to fix it immediately before non-conformant
> documents are unleased to wreck havoc. Your approach runs the risk of
> producing behavior that was not expected and might therefore have
> undesirable side-effects (considering the implications for e-commerce,
> among other things).

I believe that Michael Champion has it right:  the behavior of an XML processor (and not just
an SML processor) must be to 'fall forward'. Particularly in e-commerce, the salient criterion
will be what the receiving processor can *do* (i.e., what processing it is capable of
performing, in the service of its own particular interests) with whatever data, or subset of
that data, it might be presented with by a particular XML document. To do no processing of
otherwise usable data because some detail of a received document fails to meet a pre-defined
criterion is to fail to do the very thing--processing--which a processor is expected to do in
support of locally-defined function at the receiving node.

Respectfully,

Walter Perry


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 14:03:52 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:03 2004
Subject: RTFM for XML
In-Reply-To: <Pine.GSU.4.10.9911152305030.24665-100000@netcom10.netcom.c
 om>
References: <199911151901.OAA20798@hesketh.net>
Message-ID: <199911161403.JAA02854@hesketh.net>

At 11:15 PM 11/15/99 -0800, Eric Bohlman wrote:
>Whoa there!  This is starting to remind me of some of the flamewars on
>comp.lang.perl.misc over whether it's reasonable to expect a programmer to
>RTFM!  If a particular wireless protocol really does need to be usable by
>script kiddies [1], then the solution, to the extent that one is possible,
>is to hide all the details in an application-specific API.  If someone
>doesn't want to understand what XML is, to the extent of knowing what an
>external entity is, they should *not* be using an API that's expressed in
>terms of XML constructs!  If the protocol can't handle external
>entitities, yet needs to be usable by Web Slaves who wouldn't know a
>markup language from a hole in the ground, then you need an API whose
>implementation isn't capable of generating external entity references.
>It's that simple.

If the point of XML was just to make life easier for programmers who knew
all about XML to start with, I'd have no problem with this point of view.

However, since XML is still moving out into the world from a _tiny_ base of
users, all of whom are far too busy, I often find it depressing that its
creators find its oddities and inconsistencies barely worth a note.  

I've heard "but there's nothing wrong with it!" in regard to both XML 1.0's
stranger complexities and in namespaces, and in both cases I think we've
lost key opportunities that go well beyond RTFM.  (Especially since the
Desperate Perl Hacker, DPH, a 'script kiddie' was supposedly key in XML's
early development.)

Since I seem to keep writing manuals, I suppose this is a profit-center for
me, but I'd be a lot happier writing about how to build funkier XML-based
applications rather than warning people again and again that mixing MSXML
or Aelfred with Expat is often a bad idea.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From matthew at praxis.cz  Tue Nov 16 14:11:43 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
References: <3.0.32.19991115091953.014ad9e0@pop.intergate.ca> <00bf01bf2fb0$9e87c230$e5bdb3c7@PTGRESTON> <38312A96.95E2E605@praxis.cz> <38315844.96455398@fiduciary.com>
Message-ID: <383165D3.FC93A06F@praxis.cz>

W. E. Perry wrote:
> I believe that Michael Champion has it right:  the behavior of an XML processor (and not just
> an SML processor) must be to 'fall forward'. Particularly in e-commerce, the salient criterion
> will be what the receiving processor can *do* (i.e., what processing it is capable of
> performing, in the service of its own particular interests) with whatever data, or subset of
> that data, it might be presented with by a particular XML document. To do no processing of
> otherwise usable data because some detail of a received document fails to meet a pre-defined
> criterion is to fail to do the very thing--processing--which a processor is expected to do in
> support of locally-defined function at the receiving node.

Okay, I strongly disagree with this. If a processor has a mechanism for
saying, for example, that it does not accept PIs, and nevertheless
receives a document with PIs, then there is reason to doubt that the
initiating system is conforming to its contract. Trying to "guess" that
the user really *did* mean to order an extra 100,000 widgets when a
non-conformant request has been received seems rather dangerous to me.
But I'd be interested to hear what others think.

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 14:19:33 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <38315844.96455398@fiduciary.com>
Message-ID: <001801bf303d$6ee1e6e0$ab20268a@pc-lrd.bath.ac.uk>

> I believe that Michael Champion has it right:  the behavior of an
> XML processor (and not just an SML processor) must be to 'fall forward'.
> Particularly in e-commerce, the salient criterion will be what the
receiving
> processor can *do* (i.e., what processing it is capable of performing, in
the
> service of its own particular interests) with whatever data, or subset of
> that data, it might be presented with by a particular XML document.

I'd have said an e-commerce app would have been an all or nothing
application.
Transactions should be atomic.

If I sent you an e-commerce order, and I've accidentally (or mistakenly)
sent you my
company name in an external entity, what will you do with the order. Buy in
the
stock, but have nowhere to ship/charge it? What if I've incorrectly coded
the amount of stock I want - how much will you send/charge me?

> To do no processing of otherwise usable data because some detail of a
received
> document fails to meet a pre-defined criterion is to fail to do the very
thing
> --processing--which a processor is expected to do in support of
locally-defined
> function at the receiving node.

What if that detail is the whole point of the transaction? What useful
information
is left? How do you decide how incomplete the document/message/fragment can
be before the transaction becomes useless? Do you have to apply heuristics
to
determine which bits of data are relevant/fail-safe?

If some 'detail' is irrevelant then why is it being sent in the first place?
You can therefore prune your protocol further.

All or nothing is at least safe.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 14:44:30 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:17:03 2004
Subject: APIs vs Markup
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F278105@MDYNYCMSX1>

At 08:00 AM 11/13/99 -0800, Don Park wrote:
>For example, log data tends to just accumulate 
>and one has to use XML hacks to make the data meet
>the root element constraint. 

It would be simple enough to append logEntry elements to whatever.log and
then, when you need to process it as a valid XML document, to process this:

  <!DOCTYPE myLog [
  <!ELEMENT myLog (logEntry+)>
  <!-- declare logEntry, etc. -->
  <!ENTITY logfile SYSTEM "whatever.log">
  ]>
  <myLog>&logfile;</myLog>

I would consider this an obvious use of a basic XML feature (external
general entities); is this what you meant by "XML hack"?

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 14:38:04 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeling good about SML
In-Reply-To: <3.0.6.32.19991116115426.0092c690@gpo.iol.ie>
Message-ID: <Pine.GSU.4.10.9911160608590.948-100000@netcom18.netcom.com>

On Tue, 16 Nov 1999, Sean Mc Grath wrote:

> I think there is a step before SML which -- if it went well --
> might even remove the need for SML:
> 
> 1) Tie down what the bifurcation areas that cause XML
> interoperability problems and allow people to throw
> the phrase "XML parser" around with wild abandon.
> e.g. external subset processing, external entity references,
> Unicode encoding(s) supported, location information, etc. etc.
> 
> For arguments sake, lets call this the XML Feature Manifest
> (XMF).

I think there's a step or two before even that.  We've been talking about
"simplifying" XML without sharing an operational definition of "simpler."
I've seen people interpret in this discussion in at least three senses:

1) Requiring less code to parse.

2) Requiring fewer characters to be transmitted over a communication link.

3) Requiring less time and effort to learn.

These senses are orthogonal; efforts that achieve one may not necessarily
help with the others, and may make matters worse.

I'm not convinced that 1) is even a problem, and I believe people like
David M. when they say that subsetting features would not result in a
substantial footprint reduction for a well-written parser.  I think what
we have here is really an issue of API complexity, but APIs can be
simplified without touching the language itself.

For example, it would be reasonable for a parser to be used in a wireless
device to have very little error-reporting ability; a simple go/no-go
indication would be enough.  Such a parser probably doesn't need
facilities for obtaining the character position of an error or the exact
nature of the error; there's nothing the user of the device would be able
to do with that information anyway.  Therefore, such a parser wouldn't
need to store code for error messages.  Anybody who needed to debug the
data being sent could use a bigger parser on a desktop machine.  Nothing
about XML itself mandates the presence of development-tool hooks in a
parser API, yet the presence or absence of such hooks can make a big
difference in a parser's footprint.

2) can be handled transparently to the language itself.  One can either
use standard general-purpose compression mechanisms, or mechanisms (like
SHORTTAG encoding) that take advantage of the textual properties of the
language.

3) is really a matter of simplifying APIs, not the language itself.  I
don't believe the cognitive load of XML according to the W3C
recommendation is excessively high for a programmer who needs to write
code for generic XML processing.  If a programmer only needs to deal with
a handful of XML applications, the solution is to create
application-specific APIs for those applications.  The user of such APIs
shouldn't have to even be concerned with the fact that the data is going
in and coming out as XML.

To sum it up, before we can decide *how* to simplify XML, we need to
decide *why* we need to, and *if* simplifying the language itself is the
solution.  Otherwise we run the risk of premature closure, constructing a
problem definition based on the characteristics of the perceived solution.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 14:52:26 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeling good about SML
In-Reply-To: <3.0.6.32.19991116115426.0092c690@gpo.iol.ie>
References: <000001bf301e$f93c6460$099918d1@docuverse1>
Message-ID: <199911161451.JAA05295@hesketh.net>

At 11:54 AM 11/16/99 +0000, Sean Mc Grath wrote:
>For arguments sake, lets call this the XML Feature Manifest
>(XMF).
>
>I don't know to what extent this overlaps
>with Simon St. Laurent because I cannot
>connect to his site right now. Sorry.

Hmmm... I'll have to check my log files.  The 'canonical' URL is
http://purl.oclc.org/NET/xpdl, but http://www.simonstl.com/projects/xpdl/
also works if for some reason the PURL resolver is down, which happens
periodically.

I like the idea a lot, though I'm having a hard time figuring out exactly
how the overlap would work.  XPDL lets you create document types, which can
then provide information like "you're missing something if you don't
default attributes here" - "get these entities or this document is toast" -
"you need namespace processing to understand this document" - "XPointer is
the fragment identifier used for this type of document", etc.

You could extend it pretty easily to profile XML, probably in the space
I've created for indicating XLink, XPointer, and namespaces support.

I like this idea very much, but I'm not sure that it'll work so well with
SML, which seems to be aiming for the simplest possible framework. Even a
PI pointing to this info might be too much, even if I said XPDL files had
to be canonicalized.  (Right now, they're not.)

In general, I have to say my sympathies are with the simplifiers.  I'd much
rather see developers start from the simplest possible base and build out
than require them to understand all the parts involved in XML 1.0.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From schampeo at hesketh.com  Tue Nov 16 15:02:20 1999
From: schampeo at hesketh.com (Steven Champeon)
Date: Mon Jun  7 17:17:03 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <Pine.GSU.4.10.9911152305030.24665-100000@netcom10.netcom.com>
Message-ID: <Pine.LNX.3.95.991116093937.4152A-100000@wasabi.hesketh.net>

On Mon, 15 Nov 1999, Eric Bohlman wrote:
> On Mon, 15 Nov 1999, Simon St.Laurent wrote:
> > Try explaining this glitch to people who don't understand XML well enough
> > to understand what an 'external entity' is a few hundred times, and perhaps
> > your opinion of its importance will change.  The guy who used '&mycompany;'
> > may know what it means, but the lucky troubleshooter on the other end may
> > well not know - and probably shouldn't have to know.
> > 
> > We're probably stuck with the mess, but unfortunately it's a very big deal
> > to certain classes of users, particularly those who'd like XML application
> > to process XML documents without a lot of oversight about 'what XML really
> > is'.
> 
> Whoa there!  This is starting to remind me of some of the flamewars on
> comp.lang.perl.misc over whether it's reasonable to expect a programmer to
> RTFM!  If a particular wireless protocol really does need to be usable by
> script kiddies [1], then the solution, to the extent that one is possible,
> is to hide all the details in an application-specific API.

I guess what bothers me a bit about this whole discussion is the implicit
assumption that it's somehow *bad* to use abstraction to hide the details;
that it's somehow a mark of weakness to want to be able to do:

 $doc = new XML::Document($url);
 $doc->transform($stylesheet, $ENV{'HTTP_USER_AGENT'});
 print $doc;
 # or whatever

It's been almost two years since I was part of this list, and it's odd to 
come back to it only to find the same endless discussions of whether or
not XML should be easy. Of course it should. It doesn't harm anyone if the
tools are abstracted to the point of usability, does it?

Steve
-- 
business: http://hesketh.com ...custom medium- to large-scale web sites
the book: http://dhtml-guis.com  ...Building Dynamic HTML GUIs from IDG
punditry: http://a.jaundicedeye.com       ...negative forces have value
personal: http://hesketh.com/schampeo/  ...info, projects, random stuff



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 15:44:25 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <Pine.LNX.3.95.991116093937.4152A-100000@wasabi.hesketh.net
 >
References: <Pine.GSU.4.10.9911152305030.24665-100000@netcom10.netcom.com>
Message-ID: <199911161543.KAA08586@hesketh.net>

At 10:02 AM 11/16/99 -0500, Steven Champeon wrote:
>It's been almost two years since I was part of this list, and it's odd to 
>come back to it only to find the same endless discussions of whether or
>not XML should be easy. Of course it should. It doesn't harm anyone if the
>tools are abstracted to the point of usability, does it?

That's it exactly.  There's no good reason for XML to be hard - there's no
good reason programmers should have to know the ins and outs of XML to be
able to process XML documents reliably.  Abstracting all this work to the
'parser' (which works by magic, right?) has made XML much more usable than
its competition.  Unfortunately, the contents of documents may vary
depending on which parser you choose.

The more things change...

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From wperry at fiduciary.com  Tue Nov 16 15:40:34 1999
From: wperry at fiduciary.com (W. E. Perry)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeler for SML (Simple Markup Language)
References: <001801bf303d$6ee1e6e0$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <38317ACB.DABEE8D6@fiduciary.com>

Leigh Dodds wrote:

> I'd have said an e-commerce app would have been an all or nothing application.
> Transactions should be atomic.

Yes, it is precisely the e-commerce *app* which should be all-or-nothing *on its own terms*.
That is, a particular process defined and executed at the receiving node either will, or will
not, have all of the input data it requires. The definition of that data requirement is local:
the sending node supplies data, presumably conforming to a definition which makes sense to the
sender, but is not entitled to specify for the receiver the particular definition either of
the data or of the processes to be performed on it. And, yes, transactions should be atomic
but, again, on their own terms. The atomicity of the transaction is only from the point of
view of the (receiving) node which executes it. From the point of view of the node sending the
data which triggers a remote transaction, the 'atomic' transaction may well include (and in
the execution of trades in securities--the example you use below--nearly always does include)
several such remote pieces.

> If I sent you an e-commerce order, and I've accidentally (or mistakenly) sent you my company
> name in an external entity, what will you do with the order. Buy in the stock, but have
> nowhere to ship/charge it? What if I've incorrectly coded the amount of stock I want - how
> much will you send/charge me?

Let's make these examples real. Execution of orders in securities does not occur in a vacuum.
In order to accept an order to deal on your behalf, or to deal with you as principal, I must
know enough about you to be able to confirm, compare and settle the transaction. It's not
merely that I can't execute the trade if I don't know your company name:  I can't execute it
even with your company name if I do not know your confirmation and settlement details. In
other words, to get to the point where you can send me an order for execution, we have already
gone through significant exchanges of data, to establish the context in which that trade,
legally as well as logistically, might be executed.If after all that you neglect on one
occasion to send your name with the order, then if I know the provenance of the message I
already know who you are, and I can supply the missing data. If the data missing on that
occasion is a crucial detail particular to that trade (see your objections just below) then,
because I know who you are (from context previously established) and know the provenance of
the message you have sent me, I can (programmatically, from my processor) send you a message
requesting the missing details which I require to consummate the transaction.

> What if that detail is the whole point of the transaction? What useful information is left?
> How do you decide how incomplete the document/message/fragment can be before the transaction
> becomes useless? Do you have to apply heuristics to determine which bits of data are
> relevant/fail-safe?
>
> If some 'detail' is irrevelant then why is it being sent in the first place?

Irrelevant to the receiver, and to the processes which the receiver can perform, does not mean
irrelevant to the sender.

> You can therefore prune your protocol further.

Or, my protocol could be to derive the schema on every occasion from the data as actually
received and as instantiated within the context of locally-defined processes which the sender
may know nothing of.

> All or nothing is at least safe.

Unfortunately, it is safely nothing if we cannot process the very transactions which we went
into business to execute.

Respectfully,

Walter Perry



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 16:26:47 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:17:04 2004
Subject: W3C releases XPath and XSLT Recommendations
Message-ID: <19991116112630.A2140@w3.org>

  You can get more info, specs, press releases and testimonials
from our Web page:
   http://www.w3.org/

  I would like to publicly acknoledge and thanks for their work
the working groups, editors, and all who helped producing and
refining those specifications by reading or reporting on drafts
or by providing early implementations,

Daniel, W3C XML Linking WG staff contact

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 16:42:38 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeling good about SML
Message-ID: <3.0.32.19991116083523.014742d0@pop.intergate.ca>

At 11:54 AM 11/16/99 +0000, Sean Mc Grath wrote:
>I see this as nothing more than codifying existing
>practice. There are lots of parsers that claim
>to be XML parsers but when you look closely they
>don't do X,Y and Z per the specification.

Is that really true?  The parsers out there in the field seem to 
make heroic efforts to cross all the t's and dot all the i's.

 -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 16:52:03 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeling good about SML
Message-ID: <3.0.32.19991116085124.014e7d50@pop.intergate.ca>

At 06:37 AM 11/16/99 -0800, Eric Bohlman wrote:

>To sum it up, before we can decide *how* to simplify XML, we need to
>decide *why* we need to, and *if* simplifying the language itself is the
>solution.  Otherwise we run the risk of premature closure, constructing a
>problem definition based on the characteristics of the perceived solution.

Yes, please. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 16:57:14 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:04 2004
Subject: APIs vs Markup
In-Reply-To: <01BA10F0CD20D3119B2400805FD40F9F278105@MDYNYCMSX1>
Message-ID: <000a01bf3053$d65e8240$099918d1@docuverse1>

>It would be simple enough to append logEntry elements to 
>whatever.log and
>then, when you need to process it as a valid XML document, to 
>process this:
>
>  <!DOCTYPE myLog [
>  <!ELEMENT myLog (logEntry+)>
>  <!-- declare logEntry, etc. -->
>  <!ENTITY logfile SYSTEM "whatever.log">
>  ]>
>  <myLog>&logfile;</myLog>
>
>I would consider this an obvious use of a basic XML feature (external
>general entities); is this what you meant by "XML hack"?

Yes, Bob.  'Obvious' is rather arguable.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 17:13:19 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:17:04 2004
Subject: datatypes and i18n
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16F8C@martinique>

This message is being sent (separately) to the XML-DEV list and to the W3C
XML Schema and I18N Interest Groups.

I'd like to raise a few issues for the XML Schema WG to think about.  I know
it would make your difficult task easier if you could to see detailed
proposals, but I'm afraid it'll be some weeks before I can put one together.
I also plead guilty to not having followed the mailing list closely, read
the issues lists, or even having read the structures draft very closely.
Can't be helped; my circuits are overloaded.  

Nevertheless I think it fair to urge you to reconsider the "lexical space"
aspect of datatypes.  For starters, the notion that a lexical "space" is an
aspect of a datatype is highly suspect, IMO.  I think it more accurate to
construe the set of strings as just another type, you get more power and
flexibility that way.  Interpreting a string in various semantic fields -
number, date, name, etc. - then just becomes an issue of providing a mapping
from one type to another.  

A key point is that the values of the various semantic fields have *no*
natural lexical representation whatsoever, so the mapping is from lexemes to
pure values.  Of course one must choose a canonical metalanguage to
represent the values, but only so that users of the language may employ
whatever lexical representations they choose by mapping to the canonical
representation.  

This is one way to address the issue of internationalization that has been
raised recently regarding the boolean type.  But this problem of
Eurocentrism is everywhere in the current draft.  Another simple example:
integers.  Pick ASCII as the canonical representation, then users pick
whatever characters they like to denote the integers, mapping to ASCII 0-9.
So a document may use numeric chars from any Unicode block as the lexical
representation of integers.  Even if multiple such lexical types were used
in one document, the semantics would be the same: integer.

A more sophisticated approach would provide for a "lexical syntax"
("lexitactics"?) restricting lexical forms.  E.g. 1.23E-4.

I tried to suggest this some time ago in 

	http://www.datalogics.com/xml/xsl/wg/lextype.htm

but except for some generous help on how various numbering systems work, I
never heard a word from anybody on the WG.  It would be nice to at least
receive some feedback, even "Sorry, no time for that now" or "What a stupid
idea!"  (I've made a few minor changes to the lextype doc since September
when I first sent it; obviously it needs work but you should be able to get
the main idean.)

I've got lots of other observations but I'm afraid I'm out of time for now.
However, you can get an idea of how I think these issues should be
approached from the following material on the Z specification language:

	The Z Reference Manual (ZRM) is at
http://spivey.oriel.ox.ac.uk/~mike/zrm/

	The Final Committee Draft of the forthcoming ISO Z standard is at 

		http://www-users.cs.york.ac.uk/~ian/zstan/CD.html

I urge you to take a hard look at these documents; you'll find that much of
the work you're doing in coming up with terminology and conceptual
frameworks has already been done.  If I had more time, I'd write a nice
proposal that Z be adopted as the Official Metalanguage of the W3C.  In fact
it is possible to write the definition of XML in Z in such a way that the
full power of Z is available for defining semantically typed XML.  But with
the holidays approaching I'm sure to have even less time; maybe somebody
else would like to give it a try or collaborate?

Sincerely,

Gregg Reynolds

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 16 17:47:11 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeling good about SML
Message-ID: <3.0.6.32.19991116173619.0092d320@gpo.iol.ie>

>At 11:54 AM 11/16/99 +0000, Sean Mc Grath wrote:
>>I see this as nothing more than codifying existing
>>practice. There are lots of parsers that claim
>>to be XML parsers but when you look closely they
>>don't do X,Y and Z per the specification.
>
[Tim Bray]
>Is that really true?

I believe it is true but I would be delighted to
be wrong.

Does anyone knowledgeable in the minutia
of XML compliance care to list the extant
parsers and put them into fully XML 1.0
compliant and non-XML 1.0 compliant camps?

The next step would be to segregate the
XML 1.0 compliant parsers along the 
lines of things they do that are
"optional" per the spec. that cause
interoperability problems.

regards,

<?xml version="1.0"?>
<p>
This document has three
erors.
/p>


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



From tpassin at mitretek.org  Tue Nov 16 18:51:25 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeling good about SML
Message-ID: <001f01bf3063$726b6680$38a3f1ce@ls-.mitretek.org>


From: Sean Mc Grath <digitome@iol.ie>
<snip>

><?xml version="1.0"?>
><p>
>This document has three
>erors.
>/p>
>
</snip>

I love  it!
So much for self-documenting markup.

Tom Passin




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



From Chris_Pacetti at whittman-hart.com  Tue Nov 16 18:56:53 1999
From: Chris_Pacetti at whittman-hart.com (Chris_Pacetti@whittman-hart.com)
Date: Mon Jun  7 17:17:04 2004
Subject: unsubscribe
Message-ID: <8625682B.0067AA32.00@mail.whittman-hart.com>



unsubscribe



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 16 19:56:53 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeling good about SML
Message-ID: <003601bf3070$17ea3a80$53f96d8c@NT.JELLIFFE.COM.AU>



>At 06:37 AM 11/16/99 -0800, Eric Bohlman wrote:
>
>>To sum it up, before we can decide *how* to simplify XML, we need to
>>decide *why* we need to, and *if* simplifying the language itself is
the
>>solution.  Otherwise we run the risk of premature closure,
constructing a
>>problem definition based on the characteristics of the perceived
solution.

I note Steve DeRose from "XML: Principles, Tools, and Techniques"
10/2/97 p6
"Most computer scientists who have worked with SGML have proposed
simplifications; specifically, keeping all the structural flexibility
while losing many syntax options. I have heard of about a dozen
proposals over the years."

Language design is fun; SGML and flex/yacc are great for that.

But I sincerely believe that simplifications to XML to remove the
encoding
PI and xml:language are morally wrong.

The West has, as a benefit of the simplicity of English, good laws, good
education, capital and because of being first, created a position for
itself
where it locked out non-alphabetic countries from technological
development
for a large part of this half-century.

C and UNIX were prime agents of this. (There was no intent to do so, and
indeed the Bell people then made good by inventing UTF-8. I am not
saying they were remotely imoral: they did not have the benefit of
knowing
what impact they would had.)

It has taken years of hard work by faceless and selfless  members of
standards comittees to reach the stage where there is a glimmer of hope.
Even now the fundamentals of the internet (e.g. DNS) are tied to
ASCII: domain names in meaningless foreign languages for much
of the world. But basing things on Unicode and allowing the
current encodings (as I think Tim Bray points out, these are not
"legacy"
encodings).

Internationalization is good for many reasons: justice, fairness,
anti-colonialism perhaps, assistance, positive discrimination (actually,
it does not get anywhere near as far as that in XML: UTF-8 which
is only convenient for Western language and Bahasa
{+ some minority languages} is required). Plus it is prudent:
economic domination promotes ideological and nationalistic
conflicts.

So, even though it might be fun, I think people who want to
standardize non-internationlized technology should ask themselves
what kind of world they are creating by doing so.   And we perhaps
should ask, rather than what we are creating, what we might be
destroying by derailing XML.  Is the "convenience" of something
like SML actually just selfishness?   That may sound harsh, but
we need to think about what kind animal we are creating on the
WWW.

At university, we are trained to create languages, if we are lucky
enough
to be somewhere that teaches it right. But are we taught about
localization and/versus internationalization and its
social/political/economic
impacts?  Without the moral/political
dimension, our education is nothing.

I think it would be a sad mistake for people to think that XML's
internationalization is there merely to provide extra markets for
bloated monopolies, though with luck it may.  For some of us,
the major benefit in XML is that provides a clear toolkit by which
much of the mess of the 70s and 80s can be cleaned up; removing
internationalization from XML does not give Simple Markup
Language, but Uncle Sam Markup Language.

This is why I feel bad about SML. Please don't derail XML.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From russ_reeves at hotmail.com  Tue Nov 16 20:01:14 1999
From: russ_reeves at hotmail.com (Russ Reeves)
Date: Mon Jun  7 17:17:04 2004
Subject: Is there a Java based SGML to XML conversion tool?
Message-ID: <19991116200035.39867.qmail@hotmail.com>

Does anyone know of a Java based SGML to XML conversion tool?
Thanks

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Chris_Pacetti at whittman-hart.com  Tue Nov 16 20:27:02 1999
From: Chris_Pacetti at whittman-hart.com (Chris_Pacetti@whittman-hart.com)
Date: Mon Jun  7 17:17:04 2004
Subject: unsubscribe
Message-ID: <8625682B.006FE9EE.00@mail.whittman-hart.com>



unsubscribe



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



From kragen at pobox.com  Tue Nov 16 20:31:59 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:17:04 2004
Subject: Is there a Java based SGML to XML conversion tool?
Message-ID: <Pine.GSO.4.10.9911161529130.9687-100000@kirk.dnaco.net>

Someone asks:
> Does anyone know of a Java based SGML to XML conversion tool?

java.lang.String.String(String value) -- Java Language Definition,
Version 1.0, section 20.12.2

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 21:11:16 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:04 2004
Subject: Feeling good about SML
In-Reply-To: <003601bf3070$17ea3a80$53f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000001bf3077$59c09ce0$099918d1@docuverse1>

>I think it would be a sad mistake for people to think that XML's
>internationalization is there merely to provide extra markets for
>bloated monopolies, though with luck it may.  For some of us,
>the major benefit in XML is that provides a clear toolkit by which
>much of the mess of the 70s and 80s can be cleaned up; removing
>internationalization from XML does not give Simple Markup
>Language, but Uncle Sam Markup Language.

I was born in Korea so I appreciate your position.  However,
your opposition of SML is based on the assumption that SML will
only support UTF-8.  The list of SML features is preliminary
and, personally, I do not mind seeing SML support both UTF-8
and UTF-16 although not necessarily at the same time since
the application might require either encoding but not both.

>This is why I feel bad about SML. Please don't derail XML.

First of all, I do not believe there is any danger of XML being
derailed.  Second, is it not true that XML derailed SGML?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 16 21:52:30 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <199911161652354.SM01212@Unknown.>

> > Whoa there!  This is starting to remind me of some of the flamewars on
> > comp.lang.perl.misc over whether it's reasonable to expect a programmer to
> > RTFM!  If a particular wireless protocol really does need to be usable by
> > script kiddies [1], then the solution, to the extent that one is possible,
> > is to hide all the details in an application-specific API.
> 
> I guess what bothers me a bit about this whole discussion is the implicit
> assumption that it's somehow *bad* to use abstraction to hide the details;

I suppose I'd have to go with "dangerous" or "hazardous" - not necessarily "bad".  A 
conscientious programmer can use such dangerous things to his advantage, but a novice 
can easily use them as an excuse to become brain-dead.  Considering recent history, I 
have to refer you to the horde of "WYSIWYG" HTML editors on the market - editors 
which try to insulate novices from the code.  If these applications were a little bit 
different in their focus - say, ditching the WYSIWYG myth and generating good code - 
then they could serve a good purpose.  As things are, though, I cannot consider those 
applications anything but *bad*...precisely because of their level of abstraction.

> that it's somehow a mark of weakness to want to be able to do:
> 
>  $doc = new XML::Document($url);
>  $doc->transform($stylesheet, $ENV{'HTTP_USER_AGENT'});
>  print $doc;
>  # or whatever

If you know what you're doing, shortcuts aren't bad at all.  If your tools are trustworthy 
(unlike the aforementioned website-in-a-box tools), they can be valuable.  However, 
recent experience has taught me that the people most likely to produce Web-targeted 
tools with a high degree of abstraction are aiming those tools at precisely those people 
who shouldn't be using them.  It's kinda like handing a stick of dynamite and a lighter to 
a second-grader on the grounds that he doesn't know enough to make the explosives for 
himself.

> It's been almost two years since I was part of this list, and it's odd to 
> come back to it only to find the same endless discussions of whether or
> not XML should be easy. Of course it should. It doesn't harm anyone if the
> tools are abstracted to the point of usability, does it?

Power requires discipline.  If you're not disciplined enough to learn at least something 
about XML, maybe you shouldn't be using it.  Once you know where the pitfalls are and 
why certain things are bad ideas, then you can start building your own shortcuts - but 
getting them handed to you is just asking for trouble.

I'm not saying that all XML should be handcoded; quite the contrary.  I'm just trying to 
point out that while a power tool can be a great boon to a carpenter who knows his 
trade, buying a power tool doesn't make you a carpenter...and IMO, we should not 
encourage the mass distribution of power tools to novices.  We've seen what hacksaw 
surgery has done to HTML coding; hopefully, we can learn from that with XML.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 22:05:23 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeling good about SML
References: <3.0.32.19991116083523.014742d0@pop.intergate.ca>
Message-ID: <3831D4FF.1731CAA7@pacbell.net>

Tim Bray wrote:
> 
> At 11:54 AM 11/16/99 +0000, Sean Mc Grath wrote:
> >I see this as nothing more than codifying existing
> >practice. There are lots of parsers that claim
> >to be XML parsers but when you look closely they
> >don't do X,Y and Z per the specification.
> 
> Is that really true?  The parsers out there in the field seem to
> make heroic efforts to cross all the t's and dot all the i's.

Yes, really true.  Consider just a dozen Java parsers; they're
more or less all over the map with respect to T's and I's:

    http://www.xml.com/pub/1999/09/conformance/index.html

Although noises I've received from a variety of vendors lead
me to believe that things are going to be getting better, the
current state of things is that quite a lot of "XML parsers"
haven't done some of the _easy_ (!) bits of T-crossing and
I-dotting, making sure widely available conformance test cases
are handled right.  (That's not only for Java processors.)

That said, I'm not sure that the nonconformance issues will
very often fit into neat categories as Sean suggests.  The
notion of a sub-profile of "full XML" doesn't seem to have
been anyone's guiding principle, at least among processors
that I've looked at.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 16 22:11:11 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeling good about SML
References: <000001bf3077$59c09ce0$099918d1@docuverse1>
Message-ID: <3831D65F.87A4AC54@allette.com.au>


Don Park wrote:

> First of all, I do not believe there is any danger of XML being
> derailed.  Second, is it not true that XML derailed SGML?

I agreee with Ricko - I think that to fragment XML would cause nothing but confusion. A year
ago the talk was all "don't let XML developers get away with flouting the spec" - now we're
discussing mandating it? I dread the time when we need to choose the appropriate processors
for a document - it would be about as much fun as the browser wars were. I don't believe that
XML is so complicated that simplification is justified.

As to the question of XML derailing SGML, it simply isn't the case. Our SGML customers are
happy to stay where they are, secure in the knowledge that they can get to XML in the blink of
an eye when they need to. XML didn't derail SGML any more than it derailed databases. XML is a
facilitating syntax to make your data usable by others - if they understand this, I doubt if
many companies using SGML are the least bit bothered by XML. Excited that they can easily
repurpose their data, yes, but not bothered.


--
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 22:25:39 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeling good about SML
In-Reply-To: <Pine.GSU.4.10.9911160608590.948-100000@netcom18.netcom.com>
Message-ID: <000201bf3081$bf4444e0$099918d1@docuverse1>

>I think there's a step or two before even that.  We've been 
>talking about "simplifying" XML without sharing an operational
>definition of "simpler."

Fair enough except I believe a set of requirements will serve
the same purpose.  Without further ado, here is the first rough
cut:

1. SML shall be easier to learn than XML

Ideally, one should be able to learn the ins and outs of SML
COMPLETELY within 30 minutes.  Amount of time spent is not
important but it can be used to indirectly measure the level of
required attention span, mental model complexity, amount of
details one must remember, etc.

2. SML shall be easier to use than XML

[TBD: this needs to be broken up more]

3. SML shall be easier to implement than XML

It should be possible for an average engineer to write a fully
compliant SML parser within a week.  While there are many XML
parsers out there now, level of compliance is questionable and
amount of time and effort to implement them is greater than
originally intended for XML.

4. SML shall be compatible with XML

[TBD]

5. SML shall promote small and fast applications

[TBD: needs rewording]

6. SML shall have zero optional features.

[TBD]

Comments and suggestions are welcome,

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From schampeo at hesketh.com  Tue Nov 16 22:31:26 1999
From: schampeo at hesketh.com (Steven Champeon)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <199911161652354.SM01212@Unknown.>
Message-ID: <Pine.LNX.3.95.991116170108.27837G-100000@wasabi.hesketh.net>

On 16 Nov 1999 rev-bob@gotc.com wrote:
> > I guess what bothers me a bit about this whole discussion is the implicit
> > assumption that it's somehow *bad* to use abstraction to hide the details;
>
> I suppose I'd have to go with "dangerous" or "hazardous" - not
> necessarily "bad".  A conscientious programmer can use such dangerous
> things to his advantage, but a novice can easily use them as an excuse
> to become brain-dead.  Considering recent history, I have to refer you
> to the horde of "WYSIWYG" HTML editors on the market - editors which try
> to insulate novices from the code.  If these applications were a little
> bit different in their focus - say, ditching the WYSIWYG myth and
> generating good code - then they could serve a good purpose.  As things
> are, though, I cannot consider those applications anything but
> *bad*...precisely because of their level of abstraction.

Funny - I would have thought that it was because they sucked, rather than
because they used abstraction. Let's not ditch Java because it makes use
of design patterns, or DNS because it allows for a nice, friendly,
hierarchical model for four-byte long integers. Similarly, let's not
expect every user of XML to have to think about every tag in their tagset
when they really want to be *authoring* a document.

Stupid abstraction is bad. That doesn't mean abstraction itself is bad. annd
it doesn't mean that you don't want to know about the guts, just that there's
a time and a place for everything.

> If you know what you're doing, shortcuts aren't bad at all.  If your
> tools are trustworthy (unlike the aforementioned website-in-a-box
> tools), they can be valuable.  However, recent experience has taught me
> that the people most likely to produce Web-targeted tools with a high
> degree of abstraction are aiming those tools at precisely those people
> who shouldn't be using them.  It's kinda like handing a stick of
> dynamite and a lighter to a second-grader on the grounds that he doesn't
> know enough to make the explosives for himself.

That's silly. Recent experience has also shown me that poorly designed Web
tools exist at all levels, not just the "Let FrontPage be Your Webmaster"
level. Your metaphor is misleading and dangerous. A more appropriate
metaphor might go like this:

  "It's like a child learning how to talk before he knows the
   rules of proper grammar."

In the former, you're assuming responsibility for someone's lack of knowledge
but your response is to hide it from them for their own safety. In the latter,
the responsibility is still there, but now it's up to you to demonstrate good
grammar and in so doing, ensure that the child learns well.

Steve
-- 
business: http://hesketh.com ...custom medium- to large-scale web sites
the book: http://dhtml-guis.com  ...Building Dynamic HTML GUIs from IDG
punditry: http://a.jaundicedeye.com       ...negative forces have value
personal: http://hesketh.com/schampeo/  ...info, projects, random stuff



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 22:39:58 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeling good about SML
In-Reply-To: <3831D65F.87A4AC54@allette.com.au>
Message-ID: <000301bf3083$c991fc60$099918d1@docuverse1>

>As to the question of XML derailing SGML, it simply isn't the 
>case. Our SGML customers are happy to stay where they are,
>secure in the knowledge that they can get to XML in the blink of
>an eye when they need to. XML didn't derail SGML any more than 
>it derailed databases. XML is a facilitating syntax to make your
>data usable by others - if they understand this, I doubt if many
>companies using SGML are the least bit bothered by XML.  Excited
>that they can easily repurpose their data, yes, but not bothered.

Putting aside the justification for SML for a moment, allow me to
replace SGML with XML and XML with SML in your paragraph:

"As to the question of SML derailing XML, it simply isn't the 
case. Our XML customers are happy to stay where they are,
secure in the knowledge that they can get to SML in the blink of
an eye when they need to. SML didn't derail XML any more than 
it derailed SGML. SML is a facilitating syntax to make your
data usable by others - if they understand this, I doubt if many
companies using XML are the least bit bothered by SML.  Excited
that they can easily repurpose their data, yes, but not bothered."

It sounds like a reasonable statement if made 2 years from now.

As far as confusion goes, I think SML can be explained rather
quickly and safely as 'XML 0.5'. <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From webdev at bluprints.com  Tue Nov 16 22:47:10 1999
From: webdev at bluprints.com (Henrik)
Date: Mon Jun  7 17:17:05 2004
Subject: Fw: a dying girl's wish
Message-ID: <005a01bf3084$06f37ca0$4600a8c0@bluprints.com>

----- Original Message ----- 
From: ab ahmed, Stof til eftertanke.....
> > >
> > > > >
> > > > > BE SURE YOU READ THE END OF THIS MESSAGE  - I'll warn you it's touching
> > > > >
> > > > > S L O W D A N C E:
> > > > >
> > > > > Have you ever watched kids
> > > > > on a merry-go-round
> > > > > Or listened to the rain
> > > > > slapping on the ground?
> > > > > Ever followed a butterfly's erratic flight
> > > > > Or gazed at the sun into the fading night?
> > > > > You better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > Do you run through each day on the fly
> > > > > When you ask "How are you?"
> > > > > do you hear the reply?
> > > > > When the day is done,
> > > > > do you lie in your bed
> > > > > With the next hundred chores
> > > > > running through your head?
> > > > > You'd better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > Ever told your child,
> > > > > We'll do it tomorrow
> > > > > And in your haste, not see his sorrow?
> > > > > Ever lost touch,
> > > > > Let a good friendship die
> > > > > 'Cause you never had time
> > > > > to call and say "Hi"?
> > > > > You'd better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > When you run so fast to get somewhere
> > > > > You miss half the fun of getting there.
> > > > > When you worry and hurry through your day,
> > > > > It is like an unopened gift....
> > > > > Thrown away...
> > > > > Life is not a race.
> > > > > Do take it slower
> > > > > Hear the music
> > > > > Before the song is over.
> > > > >
> > > > > PLEASE PASS THIS ON TO HELP THIS LITTLE GIRL
> > > > >
> > > > > Dear All,
> > > > >
> > > > > I just received this mail from a friend of mine in my College.
> > > > > Please respond to it. It will mean employing a little bit of time and
> > > > > won't cost you a penny. All it needs is the heart for you to send this mail.
> > > > > PLEASE pass this mail on to everybody you know.It is the request
> > > > > of a little girl who will soon leave this world as she has been a victim of the
> > > > > terrible disease called CANCER. Thank you for your effort, this isn't a chain
> > > > > letter,but a choice for all of us to save a little girl that's dying of a
> > > > > serious and fatal form of cancer.  Please send this to everyone you
> > > > > know...or don't know.  This little girl has 6 months left to live, and her
> > > > > dying wish, she  wanted to send a letter telling everyone to live their life
> > > > > to the fullest, since she never will. She'll never make it to the prom,
> > > > > graduate from high school, or get married and have a family of her own. By
> > > > > you sending this to as many people as possible, you can give her and her
> > > > > family a little hope, because with every name that this is sent to, The
> > > > > American Cancer Society will donate 3 cents per name to her treatment and
> > > > > recovery plan. One guy sent this to 500 people!!!!  So,I know that we can
> > > > > send it to at least 5 or 6. Come on you guys.... and if you're too selfish
> > > > > to take 10-15 minutes scrolling this and forwarding it to EVERYONE, then you
> > > > > are one sick person.  Just think it could be you one day. It's not even your
> > > > > money, just your time!!!  PLEASE PASS ON
> > > > >
> > > > >
> > > > >
> > > > > Dr. Dennis Shields
> > > > > Professor
> > > > >
> > > > > Department of Developmental and Molecular Biology
> > > > > Albert Einstein College of Medicine of Yeshiva University
> > > > > 1300 Morris Park Avenue
> > > > > Bronx, New York 10461
> > > > > Phone 718-430-3306
> > > > >




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 16 23:13:12 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeling good about SML
References: <000301bf3083$c991fc60$099918d1@docuverse1>
Message-ID: <3831E4E4.33E38E8A@allette.com.au>


Don Park wrote:

> Putting aside the justification for SML for a moment, allow me to
> replace SGML with XML and XML with SML in your paragraph:
>
> "As to the question of SML derailing XML, it simply isn't the
> case. Our XML customers are happy to stay where they are,
> secure in the knowledge that they can get to SML in the blink of
> an eye when they need to. SML didn't derail XML any more than
> it derailed SGML. SML is a facilitating syntax to make your
> data usable by others - if they understand this, I doubt if many
> companies using XML are the least bit bothered by SML.  Excited
> that they can easily repurpose their data, yes, but not bothered."
>
> It sounds like a reasonable statement if made 2 years from now.

I think it's a completely different thing. When we developed SGML systems for people in the
past, it was by and large sold as a safe storage mechanism, capable of making their
information useable in fifty years time. We couldn't tell them that it was going to be easy to
print or otherwise view their data - in fact in most cases we had to ensure that they could
live with these difficulties. SGML was and is about future-proofing data.

XML is not about storage per se - in fact it is widely accepted that many documents will have
a life as short as the time that it takes for two applications to connect and transfer. XML is
a facilitating syntax - that's one of the major reasons that the SGML community accepted it as
a good thing, and why many of that community still scoff at the "SGML is too hard" mantra. If
XML had been aligned more as a replacement for SGML, the attitudes may well have been
different, so perhaps our different opinions reflect our perceptions about the longevity of
SGML.

With SGML much of the control was managed by the SGML declaration - I believe that if you want
to support less that the entire XML recommendation it should be handled by a similar
mechanism. I don't believe that dumbing down requirements is going to result in a healthy,
ubiquitous suite of applications.


--
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 16 23:13:04 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeling good about SML
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16F99@martinique>

The big difference is the SGML choo-choo was not going anywhere, so
derailing it would have been quite a feat.  The funding that has gone into
XML was not taken from the SGML budget.

But I would not discourage DPSML.  (How about "VML", on grounds that "V" is
half of "X"?  Or maybe "\ML" or "/ML" would be better.)  My own wishlist,
since XMas is approaching, is that Santa deliver 1) a charstring -> tag
mapping so we can recapture the glories of shortrefs, and 2) a distinction
between structural and attributional tags.  I want to be able to say that
_bar_ means <foo>bar</foo>; and I want to be able to say that <section> is
structural, but <quote> is not, it only slathers its content with
attributes.  I mean, isn't it dumb to say that e.g. highlighted text is not
at the same _structural_ level as the surrounding text?  Santa's Markup
Language, anyone?

-grinning gregg

> -----Original Message-----
> From: Don Park [mailto:donpark@docuverse.com]
> Sent: Tuesday, November 16, 1999 4:42 PM
> 
> >As to the question of XML derailing SGML, it simply isn't the 
> >case. Our SGML customers are happy to stay where they are,
> 
> Putting aside the justification for SML for a moment, allow me to
> replace SGML with XML and XML with SML in your paragraph:
> 
> "As to the question of SML derailing XML, it simply isn't the 
> case. Our XML customers are happy to stay where they are,
> 
> It sounds like a reasonable statement if made 2 years from now.
> 

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



From webdev at bluprints.com  Tue Nov 16 23:17:48 1999
From: webdev at bluprints.com (Henrik)
Date: Mon Jun  7 17:17:05 2004
Subject: Fw: a dying girl's wish
Message-ID: <007201bf3088$3e7e18c0$4600a8c0@bluprints.com>

----- Original Message ----- 
From: ab ahmed, Stof til eftertanke.....
> > >
> > > > >
> > > > > BE SURE YOU READ THE END OF THIS MESSAGE  - I'll warn you it's touching
> > > > >
> > > > > S L O W D A N C E:
> > > > >
> > > > > Have you ever watched kids
> > > > > on a merry-go-round
> > > > > Or listened to the rain
> > > > > slapping on the ground?
> > > > > Ever followed a butterfly's erratic flight
> > > > > Or gazed at the sun into the fading night?
> > > > > You better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > Do you run through each day on the fly
> > > > > When you ask "How are you?"
> > > > > do you hear the reply?
> > > > > When the day is done,
> > > > > do you lie in your bed
> > > > > With the next hundred chores
> > > > > running through your head?
> > > > > You'd better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > Ever told your child,
> > > > > We'll do it tomorrow
> > > > > And in your haste, not see his sorrow?
> > > > > Ever lost touch,
> > > > > Let a good friendship die
> > > > > 'Cause you never had time
> > > > > to call and say "Hi"?
> > > > > You'd better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > When you run so fast to get somewhere
> > > > > You miss half the fun of getting there.
> > > > > When you worry and hurry through your day,
> > > > > It is like an unopened gift....
> > > > > Thrown away...
> > > > > Life is not a race.
> > > > > Do take it slower
> > > > > Hear the music
> > > > > Before the song is over.
> > > > >
> > > > > PLEASE PASS THIS ON TO HELP THIS LITTLE GIRL
> > > > >
> > > > > Dear All,
> > > > >
> > > > > I just received this mail from a friend of mine in my College.
> > > > > Please respond to it. It will mean employing a little bit of time and
> > > > > won't cost you a penny. All it needs is the heart for you to send this mail.
> > > > > PLEASE pass this mail on to everybody you know.It is the request
> > > > > of a little girl who will soon leave this world as she has been a victim of the
> > > > > terrible disease called CANCER. Thank you for your effort, this isn't a chain
> > > > > letter,but a choice for all of us to save a little girl that's dying of a
> > > > > serious and fatal form of cancer.  Please send this to everyone you
> > > > > know...or don't know.  This little girl has 6 months left to live, and her
> > > > > dying wish, she  wanted to send a letter telling everyone to live their life
> > > > > to the fullest, since she never will. She'll never make it to the prom,
> > > > > graduate from high school, or get married and have a family of her own. By
> > > > > you sending this to as many people as possible, you can give her and her
> > > > > family a little hope, because with every name that this is sent to, The
> > > > > American Cancer Society will donate 3 cents per name to her treatment and
> > > > > recovery plan. One guy sent this to 500 people!!!!  So,I know that we can
> > > > > send it to at least 5 or 6. Come on you guys.... and if you're too selfish
> > > > > to take 10-15 minutes scrolling this and forwarding it to EVERYONE, then you
> > > > > are one sick person.  Just think it could be you one day. It's not even your
> > > > > money, just your time!!!  PLEASE PASS ON
> > > > >
> > > > >
> > > > >
> > > > > Dr. Dennis Shields
> > > > > Professor
> > > > >
> > > > > Department of Developmental and Molecular Biology
> > > > > Albert Einstein College of Medicine of Yeshiva University
> > > > > 1300 Morris Park Avenue
> > > > > Bronx, New York 10461
> > > > > Phone 718-430-3306
> > > > >




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



From rev-bob at gotc.com  Tue Nov 16 23:34:48 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:05 2004
Subject: Feeler for SML (Simple Markup Language)
Message-ID: <199911161833821.SM01664@Unknown.>

> On 16 Nov 1999 rev-bob@gotc.com wrote:
> > > I guess what bothers me a bit about this whole discussion is the implicit
> > > assumption that it's somehow *bad* to use abstraction to hide the details;
> >
> > I suppose I'd have to go with "dangerous" or "hazardous" - not
> > necessarily "bad".  A conscientious programmer can use such dangerous
> > things to his advantage, but a novice can easily use them as an excuse
> > to become brain-dead.  Considering recent history, I have to refer you
> > to the horde of "WYSIWYG" HTML editors on the market - editors which try
> > to insulate novices from the code.  If these applications were a little
> > bit different in their focus - say, ditching the WYSIWYG myth and
> > generating good code - then they could serve a good purpose.  As things
> > are, though, I cannot consider those applications anything but
> > *bad*...precisely because of their level of abstraction.
> 
> Funny - I would have thought that it was because they sucked, rather than
> because they used abstraction.

And what sucks about them?  IMO, they suck because they take abstraction too far 
without being trustworthy in doing so.  Not only is the sort of abstraction faulty (HTML 
as WYSIWYG?!?!?), but the produced code is faulty...and yet, the products are 
advertised as trustworthy substitutes for knowledge.  This is why they suck - faulty 
abstraction, pure and simple.

> Let's not ditch Java because it makes use of design patterns, or DNS because it allows
> for a nice, friendly, hierarchical model for four-byte long integers. Similarly, let's not
> expect every user of XML to have to think about every tag in their tagset when they
> really want to be *authoring* a document.

Now, call me strange, but I don't see the correlation here.  I'm saying abstraction **CAN 
BE** bad (and hence **IS** dangerous - danger being that which can lead to bad 
results) because it encourages people to think lazily.  Perhaps my point will be clearer if I 
explain that I'm all in favor of automation - but if you don't know what you're 
automating, you will get into trouble.  Heck, my site is automated to the hilt - and yet, I 
control every last byte that comes out.  See the distinction?

> Stupid abstraction is bad. That doesn't mean abstraction itself is bad. annd
> it doesn't mean that you don't want to know about the guts, just that there's
> a time and a place for everything.

I never said abstraction was inherently bad - I called it dangerous because, if not used 
carefully, it can become bad.  Explosives can be used intelligently to collapse a building 
with no collateral damage, or they can be used stupidly.  It is this very versatility, 
coupled with their ease of use, which makes them dangerous.  I'm looking forward to 
www.xml for precisely one reason: XML is strict and unambiguous, in stark contrast to 
HTML's looseness and ambiguity.  This looseness has allowed a lot of bad tools to pop 
up, gaining popularity despite the hideous code they generate - and why?  Because 
they're abstract enough that any idiot can use 'em.

> > If you know what you're doing, shortcuts aren't bad at all.  If your
> > tools are trustworthy (unlike the aforementioned website-in-a-box
> > tools), they can be valuable.  However, recent experience has taught me
> > that the people most likely to produce Web-targeted tools with a high
> > degree of abstraction are aiming those tools at precisely those people
> > who shouldn't be using them.  It's kinda like handing a stick of
> > dynamite and a lighter to a second-grader on the grounds that he doesn't
> > know enough to make the explosives for himself.
> 
> That's silly. Recent experience has also shown me that poorly designed Web
> tools exist at all levels, not just the "Let FrontPage be Your Webmaster"
> level.

True enough - but my point is that FP et al. are sufficiently ill-designed to churn out bad 
code, yet sufficiently well-designed to be easy to use.  This is a deadly combination, in 
that it leads to a proliferation of bad code through the ease of use allowed by a high level 
of abstraction that insulates the trusting user from knowing he's producing bad code.  
There are poorly designed tools in every field; is that an excuse to promote them in a 
new field?

> Your metaphor is misleading and dangerous. A more appropriate metaphor might go
> like this:
> 
>   "It's like a child learning how to talk before he knows the
>    rules of proper grammar."
> 
> In the former, you're assuming responsibility for someone's lack of knowledge
> but your response is to hide it from them for their own safety. In the latter,
> the responsibility is still there, but now it's up to you to demonstrate good
> grammar and in so doing, ensure that the child learns well.

The problem with your new metaphor is that, if the child doesn't know proper grammar, 
he cannot communicate well - and thus, there is a built-in impetus for him to learn how 
to communicate correctly.  With FrontPage et al., there is no such impetus; the "child" 
never knows he is being misunderstood.  A critical level of feedback is missing there; this 
is the dangerous part.  I've seen this happen with HTML; I have no desire to see XML 
tread the same path.  Let the novices play with HTML; it's already broken.  Why should 
we make it easy for them to break XML as well?



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Tue Nov 16 23:56:06 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:06 2004
Subject: a dying girl's wish
References: <007201bf3088$3e7e18c0$4600a8c0@bluprints.com>
Message-ID: <000a01bf308e$4c8c0fc0$0b00a8c0@grissom>

I hope everyone knows this is one of the classic Internet hoaxes -- although
I've seen the amount has changed. It used to read two cents per name.

For more information about Internet hoaxes, you can check the newgroup
archives using http://www.deja.com

Try alt.folklore.internet, alt.folklore.urban and other newsgroups.



----- Original Message -----
From: Henrik <webdev@bluprints.com>
To: <xml-dev@ic.ac.uk>
Sent: Tuesday, November 16, 1999 3:10 PM
Subject: Fw: a dying girl's wish


----- Original Message -----
From: ab ahmed, Stof til eftertanke.....
> > >
> > > > >
> > > > > BE SURE YOU READ THE END OF THIS MESSAGE  - I'll warn you it's
touching
> > > > >
> > > > > S L O W D A N C E:
> > > > >
> > > > > Have you ever watched kids
> > > > > on a merry-go-round
> > > > > Or listened to the rain
> > > > > slapping on the ground?
> > > > > Ever followed a butterfly's erratic flight
> > > > > Or gazed at the sun into the fading night?
> > > > > You better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > Do you run through each day on the fly
> > > > > When you ask "How are you?"
> > > > > do you hear the reply?
> > > > > When the day is done,
> > > > > do you lie in your bed
> > > > > With the next hundred chores
> > > > > running through your head?
> > > > > You'd better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > Ever told your child,
> > > > > We'll do it tomorrow
> > > > > And in your haste, not see his sorrow?
> > > > > Ever lost touch,
> > > > > Let a good friendship die
> > > > > 'Cause you never had time
> > > > > to call and say "Hi"?
> > > > > You'd better slow down
> > > > > Don't dance so fast
> > > > > Time is short
> > > > > The music won't last
> > > > > When you run so fast to get somewhere
> > > > > You miss half the fun of getting there.
> > > > > When you worry and hurry through your day,
> > > > > It is like an unopened gift....
> > > > > Thrown away...
> > > > > Life is not a race.
> > > > > Do take it slower
> > > > > Hear the music
> > > > > Before the song is over.
> > > > >
> > > > > PLEASE PASS THIS ON TO HELP THIS LITTLE GIRL
> > > > >
> > > > > Dear All,
> > > > >
> > > > > I just received this mail from a friend of mine in my College.
> > > > > Please respond to it. It will mean employing a little bit of time
and
> > > > > won't cost you a penny. All it needs is the heart for you to send
this mail.
> > > > > PLEASE pass this mail on to everybody you know.It is the request
> > > > > of a little girl who will soon leave this world as she has been a
victim of the
> > > > > terrible disease called CANCER. Thank you for your effort, this
isn't a chain
> > > > > letter,but a choice for all of us to save a little girl that's
dying of a
> > > > > serious and fatal form of cancer.  Please send this to everyone
you
> > > > > know...or don't know.  This little girl has 6 months left to live,
and her
> > > > > dying wish, she  wanted to send a letter telling everyone to live
their life
> > > > > to the fullest, since she never will. She'll never make it to the
prom,
> > > > > graduate from high school, or get married and have a family of her
own. By
> > > > > you sending this to as many people as possible, you can give her
and her
> > > > > family a little hope, because with every name that this is sent
to, The
> > > > > American Cancer Society will donate 3 cents per name to her
treatment and
> > > > > recovery plan. One guy sent this to 500 people!!!!  So,I know that
we can
> > > > > send it to at least 5 or 6. Come on you guys.... and if you're too
selfish
> > > > > to take 10-15 minutes scrolling this and forwarding it to
EVERYONE, then you
> > > > > are one sick person.  Just think it could be you one day. It's not
even your
> > > > > money, just your time!!!  PLEASE PASS ON
> > > > >
> > > > >
> > > > >
> > > > > Dr. Dennis Shields
> > > > > Professor
> > > > >
> > > > > Department of Developmental and Molecular Biology
> > > > > Albert Einstein College of Medicine of Yeshiva University
> > > > > 1300 Morris Park Avenue
> > > > > Bronx, New York 10461
> > > > > Phone 718-430-3306
> > > > >




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



From schampeo at hesketh.com  Wed Nov 17 00:23:21 1999
From: schampeo at hesketh.com (Steven Champeon)
Date: Mon Jun  7 17:17:06 2004
Subject: abstraction (was: re: re: Re: Feeler for SML (Simple Markup Language)
In-Reply-To: <199911161833821.SM01664@Unknown.>
Message-ID: <Pine.LNX.3.95.991116185006.27837L-100000@wasabi.hesketh.net>

On 16 Nov 1999 rev-bob@gotc.com wrote:
> > Funny - I would have thought that it was because they sucked, rather than
> > because they used abstraction.
 
> And what sucks about them?  IMO, they suck because they take abstraction
> too far without being trustworthy in doing so.  Not only is the sort of
> abstraction faulty (HTML as WYSIWYG?!?!?), but the produced code is
> faulty...and yet, the products are advertised as trustworthy substitutes
> for knowledge.  This is why they suck - faulty abstraction, pure and
> simple.

Ah, I see. So what you're saying is that if something may have negative
consequences as a result of its misuse, it should be denied to the
uninitiated. OK, that's fine. Let's start with the Bible.

> > Let's not ditch Java because it makes use of design patterns, or DNS
> > because it allows for a nice, friendly, hierarchical model for four-
> > byte long integers. Similarly, let's not expect every user of XML to
> > have to think about every tag in their tagset when they really want
> > to be *authoring* a document.

> Now, call me strange, but I don't see the correlation here.  I'm saying
> abstraction **CAN BE** bad (and hence **IS** dangerous - danger being
> that which can lead to bad results) because it encourages people to
> think lazily.  Perhaps my point will be clearer if I explain that I'm
> all in favor of automation - but if you don't know what you're
> automating, you will get into trouble.  Heck, my site is automated to
> the hilt - and yet, I control every last byte that comes out.  See the
> distinction?

No.

> > Stupid abstraction is bad. That doesn't mean abstraction itself is
> > bad. and it doesn't mean that you don't want to know about the guts,
> > just that there's a time and a place for everything.
>
> I never said abstraction was inherently bad - I called it dangerous
> because, if not used carefully, it can become bad.  Explosives can be
> used intelligently to collapse a building with no collateral damage, or
> they can be used stupidly.  It is this very versatility, coupled with
> their ease of use, which makes them dangerous.  I'm looking forward to
> www.xml for precisely one reason: XML is strict and unambiguous, in
> stark contrast to HTML's looseness and ambiguity.  This looseness has
> allowed a lot of bad tools to pop up, gaining popularity despite the
> hideous code they generate - and why?  Because they're abstract enough
> that any idiot can use 'em.

HTML began life as an SGML DTD, with such limited use that it rapidly
evolved into something else, ditching the rigor in the process. One might
argue that it was flawed from the beginning due to its use of formatting
elements like <B>, but you can't blame the failure of HTML (which, in one
sense, is its enormous success) on its looseness and ambiguity. If we've
learned anything from HTML, I should hope that it would be that HTML wasn't
abstracted /enough/, that the so-called "looseness and ambiguity" is more
the result of people writing non-validating browsers.

In fact, seeing as how the Web took off long before there was a decent
widely available HTML editor, you could blame the failure on handcoders
alone. So let's stop hiding behind these poorly-abstracted editors you
keep harping about.

Seeing as how XML is fundamentally about validation and/or
well-formedness, and that the structure has been carefull kept from the
presentation, and the logic kept separate from both, there shouldn't be
any trouble, now, should there?

> > That's silly. Recent experience has also shown me that poorly designed Web
> > tools exist at all levels, not just the "Let FrontPage be Your Webmaster"
> > level.
 
> True enough - but my point is that FP et al. are sufficiently
> ill-designed to churn out bad code, yet sufficiently well-designed to be
> easy to use.  This is a deadly combination, in that it leads to a
> proliferation of bad code through the ease of use allowed by a high
> level of abstraction that insulates the trusting user from knowing he's
> producing bad code.  There are poorly designed tools in every field; is
> that an excuse to promote them in a new field?

Again, you've introduced a straw man - I'm not promoting poorly designed
tools, I'm arguing for the utility of well-abstracted tools. This, over and
against your insistence that XML should remain in the hands of those who
arbitrarily limit their abstractions out of some misguided fear.

One could argue that the problem with FrontPage and its kind is less a
problem of poor HTML output and more of introducing a page-centric view
into what should be performed using higher-level abstractions (e.g.,
"sitelets", "areas", "chunks"). 

> > Your metaphor is misleading and dangerous. A more appropriate metaphor
> > might go like this:
> > 
> >   "It's like a child learning how to talk before he knows the
> >    rules of proper grammar."
> >
> > In the former, you're assuming responsibility for someone's lack of
> > knowledge but your response is to hide it from them for their own
> > safety. In the latter, the responsibility is still there, but now
> > it's up to you to demonstrate good grammar and in so doing, ensure
> > that the child learns well.

> The problem with your new metaphor is that, if the child doesn't know
> proper grammar, he cannot communicate well - and thus, there is a
> built-in impetus for him to learn how to communicate correctly. 

*laugh*

You've missed the point altogether. Children learn to talk before they
/ever/ have the rules of grammar explained to them. And if you think that
there is no difference between communicating "effectively" and "correctly",
you've obviously never heard a baby cry.

> With FrontPage et al., there is no such impetus; the "child" never knows
> he is being misunderstood. 

Similarly so for handcoders, and people who only test their markup in 
their own favorite browser, etc.

> A critical level of feedback is missing there; this is the dangerous
> part.  I've seen this happen with HTML; I have no desire to see XML
> tread the same path. 

You sincerely believe that the Web was ruined by lazy people with WYSIWYG
editors, don't you? Go back and ask the Mosaic folks if their browser had
a validating SGML parser. Ask the Netscape developers if there was ever
a validating SGML parser in their browser. Ask Microsoft. Ask anyone, but
you'll hear the same thing over and over. None of the SGML-aware browsers
(Amaya, Arena, etc.) ever got enough of an install base, or were difficult
to use, or introduced ridiculous changes in the interface metaphor so as
to effectively ruin their chances. Ask the Hotmetal people how well it
was received when they hardcoded HTML DTDs into the editor.

HTML was not ruined by a lack of feedback, it was a natural evolution from
<B> to <IMG> to <TABLE>s used as layout containers. Netscape's attempt to
break with HTML's flaws by introducing a multimedia-influenced LAYER DOM
was called all manner of evil names, but it was at least true to the Web
that HTML started, while trying to fix some of the worse flaws.

> Let the novices play with HTML; it's already broken.  Why should we make
> it easy for them to break XML as well?

How will making something easy to use, while not surrendering its inherent
robustness, make it easy for novices to break it? If anything, it seems to
me that it will ensure it's success.

I find it extremely difficult to say the same about requiring everyone to
hand-code their own start- and end-tag handlers, thereby virtually
guaranteeing that one of the following happens:

 1) people who aren't programmers will stay away from XML
 2) bad programmers will screw up XML worse than they did HTML

Steve
-- 
business: http://hesketh.com ...custom medium- to large-scale web sites
the book: http://dhtml-guis.com  ...Building Dynamic HTML GUIs from IDG
punditry: http://a.jaundicedeye.com       ...negative forces have value
personal: http://hesketh.com/schampeo/  ...info, projects, random stuff


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 00:31:17 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:06 2004
Subject: Feeling good about SML
References: <000001bf3077$59c09ce0$099918d1@docuverse1>
Message-ID: <3831F5E7.33F8@hiwaay.net>

Don Park wrote:
> 
>  Second, is it not true that XML derailed SGML?

Not really.  I got a phone call yesterday from someone 
about to bid on a very lucrative contract that specified 
SGML and precluded XML specifically.  Some still see it 
as the more powerful choice and spend their dollars 
accordingly.  It mystified me, but that was the way 
the RFP read.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 00:31:15 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:06 2004
Subject: Feeling good about SML
References: <3.0.6.32.19991116173619.0092d320@gpo.iol.ie>
Message-ID: <3831F497.3B77@hiwaay.net>

Sean Mc Grath wrote:
> 
> Does anyone knowledgeable in the minutia
> of XML compliance care to list the extant
> parsers and put them into fully XML 1.0
> compliant and non-XML 1.0 compliant camps?
> 
> The next step would be to segregate the
> XML 1.0 compliant parsers along the
> lines of things they do that are
> "optional" per the spec. that cause
> interoperability problems.

I am sort of surprised this isn't already 
done.  One of the first things done for 
X3D and VRML was to get NIST involved in 
conformance testing.  It didn't fix the 
problem with non-conformant implementations 
but it was helpful in sorting them out.  
The problem has been by the time the 
conformance tests are done, the spec 
has moved on or there are new related 
specs.  But, this was where we were in 
SGML in about 1995-96 with regards to 
using the applications.   We had to write 
up tests for the US Navy and even these 
weren't enough because they were based 
on surface characteristics.   Conformance 
testing is necessary for XML; otherwise, 
the application languages don't have a 
chance of being truly portable.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 01:16:34 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:06 2004
Subject: Feeling good about SML
In-Reply-To: <000201bf3081$bf4444e0$099918d1@docuverse1>
Message-ID: <Pine.GSU.4.10.9911161644070.2143-100000@netcom2.netcom.com>

On Tue, 16 Nov 1999, Don Park wrote:
> 1. SML shall be easier to learn than XML
> 
> Ideally, one should be able to learn the ins and outs of SML
> COMPLETELY within 30 minutes.  Amount of time spent is not
> important but it can be used to indirectly measure the level of
> required attention span, mental model complexity, amount of
> details one must remember, etc.

Learn by whom?  Learn at what level?  Consider that the formal
specification of a language, to be useful, has to be written extremely
precisely.  Yet the very precision needed will make a specification hard
to read by people who aren't used to reading formal specifications.  Do we
need the complete specification to be completely understandable in 30
minutes to someone who's never read a spec before?  Someone with no
background in logic, math, computer science, physical science, philosophy?
Keep in mind that a comma-separated format for variable-length data is
conceptually quite simple, yet there are plenty of incompatible CSV
formats and brain-dead CSV parsers out there.

Sometimes "easy to learn" really means "A developer unfamiliar with the
tool can start off at 100% productivity without having to acquire any
knowledge that would allow him to command a higher salary," i.e. "easy for
a developer to learn" really means "easy for a manger to Taylorize."

I should also point out that the amount of learning required to be able to
*implement* a tool is almost always greater than the amount of learning
required to be able to *use* that tool.  The XML Recommendation, for
example, is daunting reading for a lot of people because it describes the
language in the terms an implementor needs.  But people who are merely
going to use XML vocabularies, rather than implement XML parsers, need not
master the whole thing.

Think of an XML parser as a device driver.  An application programmer
needs to know how to use a device driver, but not how to write one.

> 3. SML shall be easier to implement than XML
> 
> It should be possible for an average engineer to write a fully
> compliant SML parser within a week.  While there are many XML
> parsers out there now, level of compliance is questionable and
> amount of time and effort to implement them is greater than
> originally intended for XML.

I question why this is important.  Writing a parser is essentially a
system programming task, not an application programming task.  It will be
done very infrequently compared to writing code that uses the parser.  To
me, the main "benefit" of this requirement seems to be to make it possible
for applications programmers to roll their own parser each time they write
an application rather than re-using a standard piece of code.  The claimed
benefit for this is usually that roll-your-own code can be more
"efficient" than general-purpose code, but that "efficiency" is usually
nothing more than micro-optimization.  Such claims seldom take total cost
into account; every roll-your-own parser has to be tested and debugged,
and cutting corners with those activities doesn't reduce your bottom-line
costs; it just smears those costs among several line-items rather than
giving them a line of their own.

This requirement comes off to me as a political concession to support NIH
cultures.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 01:37:27 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:06 2004
Subject: Parser compliance
In-Reply-To: Sean Mc Grath's message of "Tue, 16 Nov 1999 17:36:19 +0000"
References: <3.0.6.32.19991116173619.0092d320@gpo.iol.ie>
Message-ID: <m3yabxkihd.fsf@localhost.localdomain>

Sean Mc Grath <digitome@iol.ie> writes:

> Does anyone knowledgeable in the minutia of XML compliance care to
> list the extant parsers and put them into fully XML 1.0 compliant
> and non-XML 1.0 compliant camps?

Well, Expat is drop-dead, shoot-your-dog-if-it-ain't conformant, which
means that pretty much every XML implementation in Perl, C, and C++
(including Mozilla) is conformant (along with many in Python).  As far
as I've seen, XT is conformant as well.

I trust that Lark is conformant, or Tim wouldn't have put his neck on
the block by asking the question in the first place.  Likewise, David
Brownell is pretty fierce about conformance, so I imagine that Sun's
XML library (which he wrote before he left Sun) is pretty much on the
money.

I haven't looked in detail at Matt's latest AElfred versions, but when
I wrote it AElfred wass non-conformant only in its error reporting --
it will never (to my knowledge) reject a well-formed document, but
under certain circumstances, it may accept a documents that are not
well-formed.

Microsoft's parsers -- both Java and C++, embedded and stand-alone --
have never, to my knowledge, been fully conformant, though many of the 
problems are relatively obscure (for example, they all reject text
declarations without a 'version' pseudo-attribute).

IBM's implementations (XML4J and XML4C++) are so big that I haven't
really taken the time to check in detail.  I also haven't had a chance 
to test Oracle's yet.

How's that for a start?  I know that OASIS has been working on a
general conformance test suite -- it might also be nice if XML Dev'ers 
put some of their energy into a SAX conformance test suite.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 01:47:47 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:06 2004
Subject: Feeling good about SML
In-Reply-To: <Pine.GSU.4.10.9911161644070.2143-100000@netcom2.netcom.com>
Message-ID: <000201bf309d$f88aade0$099918d1@docuverse1>

Eric Bohlman wrote:
>Learn by whom?  Learn at what level?  Consider that the formal
[snip]

Like the half-a-bee, I do not have all the details yet, Eric.  <g>

If you would like to help us tighten up the list of goals, I sure
will appreciate it.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 01:58:14 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:06 2004
Subject: Do SGML and XML co-exist? (was Re: Feeling good about SML)
In-Reply-To: "Don Park"'s message of "Tue, 16 Nov 1999 14:41:51 -0800"
References: <000301bf3083$c991fc60$099918d1@docuverse1>
Message-ID: <m3vh71khxa.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> Putting aside the justification for SML for a moment, allow me to
> replace SGML with XML and XML with SML in your paragraph:
> 
> "As to the question of SML derailing XML, it simply isn't the 
> case. Our XML customers are happy to stay where they are,
> secure in the knowledge that they can get to SML in the blink of
> an eye when they need to. SML didn't derail XML any more than 
> it derailed SGML. SML is a facilitating syntax to make your
> data usable by others - if they understand this, I doubt if many
> companies using XML are the least bit bothered by SML.  Excited
> that they can easily repurpose their data, yes, but not bothered."
> 
> It sounds like a reasonable statement if made 2 years from now.

To bad it's completely wrong.  

The SGML market has flatlined, only a year and a half after XML came
out -- there are virtually no new SGML products, no new SGML books,
almost no SGML conferences, and everyone I know who has a big SGML
system is privately talking about XML migration plans (which may take
a decade in some cases).  SGML development on the major document types
and industry specs (NITF, DocBook, TEI, etc.) has ceased completely,
and all new industry document types that I've seen recently are coming
out only in XML.

This is a good thing -- it would have been fine if XML had died and
full SGML had won, and it's fine the way it is, but if both SGML and
XML had been equally strong competitors, we would have been dealing at
best with the same problem people have with OpenGL/DirectX,
CORBA/RMI/DCOM, etc.

XML's success is primarily an economic success, not a technical one,
but in the technical world economic success is what matters because
it's what delivers the network effect that makes life exciting.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 02:48:00 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:06 2004
Subject: stop programming, start integrating
Message-ID: <199911170247.VAA11517@hesketh.net>

Recent discussions about XML, SML, 'script kiddies', 'hacksaw surgery', and
the potential - not yet realized - for making things simple have left me
really wondering.  

XML has opened up some possibilities that are both intriguing and genuinely
dangerous - though more dangerous to the professional programmers than to
novices.

It seems like XML parsers are supposed to be handy tools that can be
plugged into programs without extensive thought.  I've said at any number
of conferences that I no longer call myself a programmer - I call myself an
integrator.  As an integrator, I take lots of work done by other people
(open source if possible, since it's easier to fix or customize if
necessary) and connect it to make my own projects take form.  There's
always a core bit of application logic that I get to write, but that core
is smaller and smaller and smaller all the time.

The perspective I have as an integrator is dramatically different from the
perspective I had as a developer, however.  I don't want beautifully
complete tools that represent a particular programmer or company's vision.
I don't want extra options that cause interoperability problems. I don't
want to have to deal with components that claim to be the same thing but
really aren't. I don't want 'Fix in Documentation' kinds of problems.  

I expect the applications I build to be working with applications built by
many other people along similar lines, but I won't have any control over
their development process.  Since I may be using XML to get info in and out
of my little NT box and Joe's got Linux, Josie's on a Mac, Jim's got an
AS/400, and Judy's running an S/390, talking everyone into using my code
doesn't make sense.

I want off-the-shelf parts that fit together without extensive pushing.
The simpler and more generic we can make XML and its supporting standards,
the better.  To me, too much of the XML discussions revolve around
programmers' concerns, making it the 'best' standard, not the most easily
integrated.  The 'gotchas' in the XML 1.0 and Namespaces in XML
recommendations may not matter to document authors or parser developers,
but they can make an integrator's life hell.

I'd like to see XML used in a ubiquitous way.  That's going to mean
integrating it with a lot of other application parts.  What we have now is
a start, but we're a long ways from the simplicity that gives tools like VB
the power to deliver a real (if slow) application without requiring
developers to build everything from the ground up.  Professional
programmers shouldn't be necessary to use XML, and neither should XML experts.

It'd be nice to think that users, including 'script kiddies' and VB and Web
developers, can stand on the shoulders of the XML core community without
having to call us up all the time to ask why things don't work, what things
mean, or how they can make their system speak XML.  It's a bit of a dream
right now, but it hardly seems impossible.  It'll take a change of
attitude, for some a change of business model, and possibly - eventually -
a change in the way the core specs are built.

Okay, enough dreaming.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Wed Nov 17 03:03:33 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:06 2004
Subject: abstraction
Message-ID: <199911162202411.SM01256@Unknown.>

Okay, my first version of this response just wound up being far too huge.  To make 
things really simple, here's the point I'm trying to make:

Abstraction is a tool.  It's neither good nor bad in and of itself - no more than a chainsaw 
is.  However, with any tool, its potential to be Really Good is matched by potential to be 
Really Bad, and the more powerful it is, the greater *BOTH* of those potentials are.  
This is what I'm talking about by "danger" in this context; if we give XML (a really 
powerful structure) a really high level of abstraction (putting that power in the hands of 
the masses), we will have something really powerful.  This is not necessarily a good 
thing, and that's all I'm really trying to say.  (A nuclear bomb is really powerful, but tell 
the people affected by one that its power is beneficial.)

So far, we have exactly one example class of high abstraction authoring tools on the Web 
- the WYSIWYG HTML editor.  Is there really anyone here who will argue that the 
development of this class was a good thing?  The questions about where this concept 
failed are, for my purposes, largely irrelevant; I am merely pointing out that high 
abstraction and ease of content generation is by no means a formula for a good tool.  In 
short(er), I'm just trying to urge caution and thought before we charge gung-ho down this 
path.

Now, as for amplification on specific points....

> Ah, I see. So what you're saying is that if something may have negative
> consequences as a result of its misuse, it should be denied to the
> uninitiated. OK, that's fine. Let's start with the Bible.

I'm not saying that dangerous things should never be used - what I *am* saying is that 
when you're using something dangerous, you should at least know that risks are involved 
and how to deal with them.  (And as far as the Bible goes, since you bring it up, I 
consider it absolutely unconscionable to indoctrinate children in *any* religious belief 
structure before they're old enough to actually consider and weigh the beliefs involved.  
"Because Mommy says so" is not a sufficient foundation for faith - but that's a topic for 
a private thread.)

> > Perhaps my point will be clearer if I explain that I'm all in favor of automation -
> > but if you don't know what you're automating, you will get into trouble.  Heck, my
> > site is automated to the hilt - and yet, I control every last byte that comes out.  See
> > the distinction?
> 
> No.

Okay, here's another try, and I'm going to attempt to make it a short one.

In terms of content generation ("author level"), my site is really simple.  A lot of code 
gets stuffed into macros for ease of use and consistency of generation; the result is that if 
I suddenly decide that for my XHTML pages, I want to transform FONT tags into UA-
sensitive CSS directives, I simply write one set of definitions, get 'em right, and go with 
it.  In one sense, this is close to what I understand of XSLT - take your content, 
transform it according to certain definitions, and send it in the desired format.  The 
interesting part is that I don't have to depend on any client software to achieve this; all 
the transformation is done either on my machine (pre-upload) or on-the-fly at the server.  
Not having a way to accomplish this with XML, the current system works pretty well.

Here's the key - the abstraction is entirely in my hands.  If it doesn't work, I don't have 
to look for another piece of software that *might* work better.  To return to the 
chainsaw metaphor, if I cut myself with it, the blame is entirely mine.  Similarly, if I 
turbocharge it, I take the extra risks and (hopefully) reap the added benefits.  If I may 
coin a term, it's a completely open abstraction, instead of the closed sort common to 
APIs and such.  ("We don't care how it works, only THAT it works.")  Just as I would 
hope none of you would trust your data to an XSLT transformation that you could not 
influence, I would not trust a site to a high-level closed abstraction.  Why?  Because time 
moves on, and even the best abstraction must change on occasion.  With a closed 
abstraction, that means buying a new tool and learning how to use it.  With an open one, 
it simply means tinkering with the one you already have and are familiar with. 

> In fact, seeing as how the Web took off long before there was a decent
> widely available HTML editor, you could blame the failure on handcoders
> alone. So let's stop hiding behind these poorly-abstracted editors you
> keep harping about.

In other words, let's stop talking about abstraction and shift to Why HTML Failed?  No, 
that's the wrong tangent.  The topic is abstraction and its potential with Web 
technologies; as such, we have to consider the existing examples.

> Seeing as how XML is fundamentally about validation and/or
> well-formedness, and that the structure has been carefull kept from the
> presentation, and the logic kept separate from both, there shouldn't be
> any trouble, now, should there?

Shouldn't, true.  Then again, since nobody in their right mind would produce a 
WYSIWYG-format HTML editor, I suppose FrontPage is just a figment of my 
imagination.  "Should" is wishful thinking; deal with what IS.  Microsoft et al. had no 
excuse to release (let alone sell) products that spit out horrible code - and yet, they did.  
(Say, didn't MSXML do fairly terrible on XML conformance tests?  Naah, this couldn't 
be a sign of history repeating itself....)

I'm simply trying to point out that high-level abstraction for Web design has been tried 
before, with spectacularly BAD results.  Is it really so much to ask that this time we 
might give the issue some really serious thought before trying the same idea again?

> One could argue that the problem with FrontPage and its kind is less a
> problem of poor HTML output and more of introducing a page-centric view
> into what should be performed using higher-level abstractions (e.g.,
> "sitelets", "areas", "chunks"). 

Possibly so.  Speaking for myself, divorcing content from formatting at the page level 
leaves me increasingly able to administer the site as a whole instead of each page as a 
separate document.  Sure, there are times I need to go in and tweak individual content 
files - but these days, that's either for the purpose of enhancing metadata relevant to that 
particular page or to bring an odd bit of code into line with a more widespread rule.  That 
sort of abstraction works wonders for my development efforts; what I am wary of is 
closed abstraction that a given author has no control over.  Yeah, saying that someone 
should be able to create a new XML document with a couple of program lines sounds 
really neat - but who writes the rules for that construction?

> > With FrontPage et al., there is no such impetus; the "child" never knows
> > he is being misunderstood. 
> 
> Similarly so for handcoders, and people who only test their markup in 
> their own favorite browser, etc.

This is precisely what I like about XML - *in theory*, I should be able to write a 
document, select or write a DTD, maybe write a set of XSL/T rendering rules for some 
odd stuff, and have it work on any XML parser.  As I understand it, XML documents 
are supposed to either work or break - no ambiguity.  I'm looking forward to that.

> You sincerely believe that the Web was ruined by lazy people with WYSIWYG
> editors, don't you?

They certainly didn't help matters.

> > Let the novices play with HTML; it's already broken.  Why should we make
> > it easy for them to break XML as well?
> 
> How will making something easy to use, while not surrendering its inherent
> robustness, make it easy for novices to break it? If anything, it seems to
> me that it will ensure it's success.

Chainsaws are easy to use; they are also extremely easy to MISuse.  That is my concern.  
FrontPage is easy to use if you're happy with broken code; I am not.  Personally 
speaking, I'll sacrifice some ease of use for clean results every time...but then, I care 
about how my documents look.  I'm concerned with getting pages up quickly, sure - but 
what does it profit me to get something up fast if nobody can read it?

There's already been talk here about conflicting XML parsers and possible fracturing of 
the spec...and this is at the developer level!  Am I really supposed to believe that this will 
get *better* by shoving it into the FrontPage "XML in a box" mold?

> I find it extremely difficult to say the same about requiring everyone to
> hand-code their own start- and end-tag handlers, thereby virtually
> guaranteeing that one of the following happens:
> 
>  1) people who aren't programmers will stay away from XML
>  2) bad programmers will screw up XML worse than they did HTML

This, folks, is why strict conformance specs and validating parsers in Web user agents 
are desirable - so that if a document is invalid, it doesn't work anywhere.  (As opposed to 
working in one parser but not in another - which is just Browser Wars: The Sequel.)

If someone can make a product that conforms strictly to the specs and yet has a high 
enough level of abstraction to be widely usable, more power to 'em - but I *am* going to 
be skeptical, for the reasons I've stated above.  If, on the other hand, this mythical 
someone has to sacrifice conformance for a higher abstraction - well, in that case, I'd 
much rather see 'em junk the project altogether.  IMO, it's better to have no tool than a 
bad tool.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 03:16:42 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:06 2004
Subject: Using XML to make it easier
Message-ID: <001301bf30aa$b1df2cb0$1918ccce@murphy>

Here's a screen shot of a new application we released earlier this week:

http://www.scripting.com/images/editSurvey.gif

It's a browser-based survey system. Before designing it, we did a prior-art review of other browser-based systems for creating surveys, and found they got bogged down when providing a way to specify a variable number of responses. Forms work well when you know exactly how many of each items are allowed, but when it's variable, you end up putting the user thru a time-consuming and error-prone process. It makes it hard to fix mistakes -- so you end up with lots of mistakes! :-(

I wanted something that would be easier, and XML provided the solution. This is not the usual reputation that XML has -- many people think it makes things more complex, but in this application and a few others we have in the pipe, it actually makes it easier.

If you want to try out the survey editor, all that's required is UserLand.Com membership, which is, of course free and open (takes less than a minute to sign up.) The URL for the survey editor is:

http://surveys.userland.com/

I hope you all check it out!

Dave Winer
UserLand Software


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991117/8c6b3007/attachment.htm
From ebohlman at netcom.com  Wed Nov 17 04:01:19 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:06 2004
Subject: abstraction
In-Reply-To: <199911162202411.SM01256@Unknown.>
Message-ID: <Pine.GSU.4.10.9911161931090.14322-100000@netcom2.netcom.com>

On 16 Nov 1999 rev-bob@gotc.com wrote:

> So far, we have exactly one example class of high abstraction authoring tools on the Web 
> - the WYSIWYG HTML editor.  Is there really anyone here who will argue that the 
> development of this class was a good thing?  The questions about where this concept 
> failed are, for my purposes, largely irrelevant; I am merely pointing out that high 
> abstraction and ease of content generation is by no means a formula for a good tool.  In 
> short(er), I'm just trying to urge caution and thought before we charge gung-ho down this 
> path.

I think one of the questions about where 'WYSIWYG' HTML editors failed
*is* extremely relevant; they failed because they offered an abstraction
of something completely different from what they could create.  They
offerred pixel placement on a grid as a metaphor for the encoding of
simple editorial structures, despite the fact that there is no inherent
mapping between the two.  They didn't simply hide implementation details
from their users; they actively misled their users about what they were
implementing.

There are going to be many XML-based markup languages that are highly
specialized for very particular tasks.  They're generally what we'd think
of as data-oriented languages rather than document-oriented languages.
The programmer developing an application that uses one of those languages
is concerned with getting a set of data with a particular structure from
point A to point B.  He should *not* have to be concerned about the way
that data is encoded during transport.  Therefore, it makes sense for him
to be using an API that is designed around the data structures themselves
rather than around the way the transport is implemented.  Just as it makes
sense for him to have an API to the machine's file system that lets him
deal at the level of named streams of characters rather than at the level
of physical disk sectors.  He should *not* be dealing directly with a
general-purpose XML parser.  The person who designs the API should be
doing that.  Any complexity (and of necessity, there will be plenty of it)
in the parser should influence the parser/API interface, *not* the
API/application interface.  There should be no need to simplify the parser
for the application writer, because the API layer should be managing the
complexity internally.

The key to all this is that the application-specific API needs to be
exactly that, application-specific.  Its purpose is not to "dumb down" a
generic parser interface; its purpose is to translate the specific into
the general.  SML strikes me as an attempt to dumb down the parser
interface in hopes of avoiding this translation.  But that's on the same
level as trying to "simplify" a network card's interface in order to
eliminate the need for sockets and let the application programmer talk to
the card directly.  Few would consider the latter a reasonable goal.

An abstraction of a chainsaw in which none of the abstract objects have
the destructive power of a chainsaw is evil and dangerous.  But that's not
what we have here.


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



From rev-bob at gotc.com  Wed Nov 17 04:31:35 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:07 2004
Subject: abstraction
Message-ID: <199911162330897.SM01256@Unknown.>

> On 16 Nov 1999 rev-bob@gotc.com wrote:
> 
> > So far, we have exactly one example class of high abstraction authoring tools on the
> > Web - the WYSIWYG HTML editor.  Is there really anyone here who will argue
> > that the development of this class was a good thing?  The questions about where this
> > concept failed are, for my purposes, largely irrelevant; I am merely pointing out that
> > high abstraction and ease of content generation is by no means a formula for a good
> > tool.  In short(er), I'm just trying to urge caution and thought before we charge
> > gung-ho down this path.
> 
> I think one of the questions about where 'WYSIWYG' HTML editors failed
> *is* extremely relevant; they failed because they offered an abstraction
> of something completely different from what they could create.

True enough; they offered a high abstraction, but it was the *wrong* abstraction.  They 
promised something they could only deliver in certain circumstances and with broken 
code - which just goes to show that making something easy to use isn't enough.  You 
also have to make it correct and make sure it is faithful both to the high concept and to 
the final code.

> They didn't simply hide implementation details from their users; they actively misled
> their users about what they were implementing.

Right.  However, it can be (and has been) argued that this was simply a way to take the 
abstraction one level higher.  Abstraction is not a magic remedy for core problems; this is 
all I'm trying to say.  Validity is critical, and IMO, it is more important than an easy-to-
use high abstraction.

> There are going to be many XML-based markup languages that are highly
> specialized for very particular tasks.  They're generally what we'd think
> of as data-oriented languages rather than document-oriented languages.

And for such tasks, I agree - a strict (and closed) abstraction level is good for such 
things.  No argument.  My primary concern is general-purpose publishing for the Web; 
please consider my comments in that light.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Wed Nov 17 04:45:01 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:17:07 2004
Subject: abstraction
References: <199911162202411.SM01256@Unknown.>
Message-ID: <004501bf30b7$071f3f60$3915b0cf@tomshp>

From: <rev-bob@gotc.com>
Subject: re: abstraction


<snip>
> Abstraction is a tool.  It's neither good nor bad in and of itself - no
more than a chainsaw
> is.  However, with any tool, its potential to be Really Good is matched by
potential to be
> Really Bad, and the more powerful it is, the greater *BOTH* of those
potentials are.
> This is what I'm talking about by "danger" in this context; if we give XML
(a really
> powerful structure) a really high level of abstraction (putting that power
in the hands of
> the masses), we will have something really powerful.  This is not
necessarily a good
> thing, and that's all I'm really trying to say.  (A nuclear bomb is really
powerful, but tell
> the people affected by one that its power is beneficial.)
>
</snip>

Abstraction is a NECESSARY thing.  How often do you deal with sockets and
packets, for example? No, we usually want to deal with HTTP and XML and XSL
and browsers, which are big-time abstractions of their own. And then sockets
are a big abstraction.  As are objects, functions, etc. Even a GIF image is
a big abstraction, not to mention file systems.

Abstractions cause undue trouble when too many layers get piled up too
"quickly", and especially when the abstraction is not a good match for
what's being abstracted.  For myself, I build some Powerbuilder
applications.  When I create a window, I get a standard window that I can
drag controls into, with a huge amount of machinery already built in.  99%
of the time, that's exactly what I want.  It's a great abstraction, because
it's easy to get something that fits my mental model.  And it's tons easier
and more productive than using MFC, for example, or the Windows API.

But when I write HTML, I generally do it by hand - usually using Cold Fusion
Studio but often with a plain editor.  I'd rather not have to, but I haven't
found tools that match my mental models well enough so far, or I still have
to do too many of the details.  But give me a graphical color palette every
time - there's a useful abstraction.

A high level of abstraction is what makes a lot of this technology
accessible to many of us.  Even sending this email.  I'm going to click on
the Send button to "send" it - now there's a great abstraction!

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 04:53:06 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:07 2004
Subject: Do SGML and XML co-exist?
Message-ID: <383233D8.46BC@hiwaay.net>

David Megginson:

>This is a good thing -- it would have been fine if XML had died and
>full SGML had won, and it's fine the way it is, but if both SGML and
>XML had been equally strong competitors, we would have been dealing at
>best with the same problem people have with OpenGL/DirectX,
>CORBA/RMI/DCOM, etc.

Interesting, but nah.  XML won because Microsoft backed 
it.  Plain and simple.  The differences between the 
features of the practice aren't that great.  The size is.
The money came and when the money voted, the money voted 
for a namechange and a change of venue.  Selah.  
Same dumb stuff, just cheaper and better integrated into 
the windowing system and the network.

>XML's success is primarily an economic success, not a technical one,
>but in the technical world economic success is what matters because
>it's what delivers the network effect that makes life exciting.

I agree with that.   SMLs success might be that it finds its 
own universal medium as HTML did.  It could happen.  So, the 
choices for the SML developers would be about the same as 
the choices of the SGML developers that developed XML.  It 
is an issue of money and media.  Economic success comes 
with control of both or it doesn't emerge.

Anyway... issues that *should* preoccupy us:

1.  Can anyone make sense of the Schemas draft without a 
narrator?  When every other word in the description is a 
hyperlinked term, there is something very complex 
going on.  Reading the specs, they link off into some 
mysterious InfoSet black hole that stops at the event horizon 
of a login.  Kind of reminds me of ... Hytime.  MMTT.  

2.  What are the conformance requirements for host languages 
and host language processors?  HTML and VRML 
qualify as hosts.  X3D will be.  What else?  SVG and VML 
appear not to be, but then there is SMIL? 

3.  Are the datatypes adequate?  Do we need the array types 
as primitives?  The X3D guys say yes.  Every place we are forced  
to build that into a host language, we get a different 
spec for a common part.  What is the reasoning to that?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.davidson at eng.sun.com  Wed Nov 17 07:52:06 1999
From: james.davidson at eng.sun.com (James Duncan Davidson)
Date: Mon Jun  7 17:17:07 2004
Subject: Parser compliance
References: <3.0.6.32.19991116173619.0092d320@gpo.iol.ie> <m3yabxkihd.fsf@localhost.localdomain>
Message-ID: <38325CA8.709B2F05@eng.sun.com>



> Likewise, David
> Brownell is pretty fierce about conformance, so I imagine that Sun's
> XML library (which he wrote before he left Sun) is pretty much on the
> money.

And the folks working on the Sun parser are still fierce about
conformance as I've been finding out. :) Even as we move to working more
and more with the xml.apache.org project, we'll continue to be fierce
about it.

.duncan


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.davidson at eng.sun.com  Wed Nov 17 07:55:48 1999
From: james.davidson at eng.sun.com (James Duncan Davidson)
Date: Mon Jun  7 17:17:07 2004
Subject: Parser compliance
References: <3.0.6.32.19991116173619.0092d320@gpo.iol.ie> <m3yabxkihd.fsf@localhost.localdomain>
Message-ID: <38325CA8.709B2F05@eng.sun.com>



> Likewise, David
> Brownell is pretty fierce about conformance, so I imagine that Sun's
> XML library (which he wrote before he left Sun) is pretty much on the
> money.

And the folks working on the Sun parser are still fierce about
conformance as I've been finding out. :) Even as we move to working more
and more with the xml.apache.org project, we'll continue to be fierce
about it.

.duncan


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



From sb at metis.no  Wed Nov 17 08:30:06 1999
From: sb at metis.no (Steinar Bang)
Date: Mon Jun  7 17:17:07 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: "Don Park"'s message of "Tue, 16 Nov 1999 13:12:52 -0800"
References: <000001bf3077$59c09ce0$099918d1@docuverse1>
Message-ID: <wh66z1h65x.fsf@viffer.oslo.metis.no>

>>>>> "Don Park" <donpark@docuverse.com>:

> I was born in Korea so I appreciate your position.  However, your
> opposition of SML is based on the assumption that SML will only
> support UTF-8.  The list of SML features is preliminary and,
> personally, I do not mind seeing SML support both UTF-8 and UTF-16
> although not necessarily at the same time since the application
> might require either encoding but not both.

Er... AFAIK you can represent the exactly the same characters in UTF-8
and UTF-16, since both are transformation formats of the full 32 bit
Unicode.  Maybe I'm missing something here...?

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



From antons at epos.co.za  Wed Nov 17 09:01:31 1999
From: antons at epos.co.za (Anton Schoultz - ePOS)
Date: Mon Jun  7 17:17:07 2004
Subject: Creating XMLDocument
Message-ID: <NBBBLIPEHIMMNAPFNOLCAEPKEBAA.antons@epos.co.za>

Hi All,

I am busy writing an API for XMLDocuments which will wrap
the classes supplied in Oracle's parser (v2) to
'hide' some of the details.

I have managed the add / remove and edit methods for 'items',
and methods to move through the document tree.
(I use 'item' to refer to {tag attributes...}data{/tag} )
I have an 'Item' class which allows add/del/upd of attributes,
data and the tag name.

I would like to know how to create a new (arbitrary) document -
How do I create the Root item ( the one with the DocType Name ) ?
Do I need to specify a DTD first? if so, how would I do this (DTDs would be
on a web server, all documents to be created would probably have a DTD
set-up and made available on the web server)

Thanks in advance

Anton Schoultz
e-mail: mailto:antons@ePOS.co.za
Office: +27 11 807-9400 Ext. 205


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



From rgl at decisionsoft.com  Wed Nov 17 09:40:35 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:07 2004
Subject: Parser compliance
In-Reply-To: <m3yabxkihd.fsf@localhost.localdomain>
Message-ID: <Pine.LNX.4.10.9911170932510.13216-100000@localhost.localdomain>

On 16 Nov 1999, David Megginson wrote:
> Sean Mc Grath <digitome@iol.ie> writes:

> > Does anyone knowledgeable in the minutia of XML compliance care to
> > list the extant parsers and put them into fully XML 1.0 compliant
> > and non-XML 1.0 compliant camps?

> Well, Expat is drop-dead, shoot-your-dog-if-it-ain't conformant...

Indeed, but it's not necessarily "fully-featured" in that it doesn't
include external entities and isn't validating, which is why we didn't
use it. One parser which does do these things is LT XML, but that isn't
very fussy about badly-formed XML (for a start, it doesn't reject
documents with more than one top-level element). So now we're onto
XML4C/Xerces.

Anyway, the point is that the issue of different XML document layouts for
different parsers is not merely one of conformance, but of the number of
optional features as well (something particularly telling in the light of
the cut-down XML debate currently continuing on this list).

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


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



From matthew at praxis.cz  Wed Nov 17 10:26:45 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:07 2004
Subject: Do SGML and XML co-exist?
References: <383233D8.46BC@hiwaay.net>
Message-ID: <383282B1.D82B1D0F@praxis.cz>

Len Bullard wrote:
> Interesting, but nah.  XML won because Microsoft backed
> it.  Plain and simple.  The differences between the
> features of the practice aren't that great.  The size is.
> The money came and when the money voted, the money voted
> for a namechange and a change of venue.  Selah.
> Same dumb stuff, just cheaper and better integrated into
> the windowing system and the network.

Yeah? I always tell the same story about the origins of XML, so I'd be
interested to know if it is wrong. :-O Basically, goes the story, round
about the genesis of HTML 4.0 the HTML folks started to realize that
even with the best of intentions and a heck of a lot of hard work they
were never going to get even a small proportion of the tags that people
(and influential companies) wanted into the language. Moreover, the
undesirability of this approach, even if practicable, was starting to
become clear (witness the length of the HTML 4.0 spec).

So they started to dream up something along the lines of generic markup
using ghastly DIV and CLASS tags. This came to the notice of the SGML
folks, who screamed bloody murder and started lobbying for SGML, with
its time-tested approach to generic markup, to be the new language for
the web. The reaction of the HTML crowd was immediate: not SGML, of all
things, it's far too scary and complicated! So some forward-thinking
types from the SGML community came up with the idea of simplying SGML
significantly in order to make it acceptable as a mass-market web
language. Whence XML.

Am I close? Assuming so, technical issues certainly were the primary
motivating factor for XML. Denying this is a pretty extreme view (not
that this surprises me, Len :-). The "features of the practice" may not
be all that different, but the fact that to write a conformant SGML
parser you needed (according to one statement I heard at an SGML
conference as XML was coming to the fore) "to have the resources of the
U.S. government or to be James Clark" surely had something to do with
the chorus of demands for simplication in exchange for ubiquity. Not
everything is a money-driven conspiracy.

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 11:04:42 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:07 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
Message-ID: <007501bf30eb$88acd860$eb020a0a@bowstreet.com>

> Er... AFAIK you can represent the exactly the same characters in UTF-8
> and UTF-16, since both are transformation formats of the full 32 bit
> Unicode.  Maybe I'm missing something here...?

I don't think this is true.

UTF-8 and UTF-16 are transformations formats of ISO10646, not Unicode.

UTF-8 gives access to all 2^31 characters from the UCS repertoire.

UTF-16, however, only gives access to the equivalent of Unicode with the
surrogate extension mechanism, ie the first 17 planes of the UCS.

James Tauber




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 11:02:10 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:07 2004
Subject: (My) Feeling About SML
Message-ID: <000801bf30eb$0141cac0$ab20268a@pc-lrd.bath.ac.uk>

I've been mulling over this whole SML/XML discussion, trying 
to get things straight in my head, and a decent summary.
I thought I'd share what I've concluded so far.

Heres where I'm at currently:

I'm not sure that parser speed/size is that much of an issue, even 
for handheld devices, and if it is I think thats the sort of 
problem thats likely to disappear quite quickly. Having an alternate 
markup language (SML/WML) is likely to cause problems later which 
are best avoided - limitations in computer processing power tend 
to go away very quickly.

I'm also not convinced about the issues raised about simplifying 
message passing for EDI and/or handhelds - as you can achieve 
this with a suitably specified specification between the parties 
involved. I've posted to this effect already.

So it seems to come down to complexity of the XML spec itself, 
and that its hard to grok all the subtleties. Now this I can 
understand (!) as I don't come from a markup background.
However it seems that this could be largely addressed with simpler APIs, 
and better documentation?

I can also understand that specifying the required (XML) feature 
subset of a document would be useful. Especially if specs start 
appearing which start saying "thou shalt not use ..." - the 
processor will need programmatic access to this information, especially 
if we start to consider compound documents and/or XML fragments.

Again, however this 'required feature subset' is handled, it doesn't 
necessarily mean that the XML 1.0 spec needs revision, it can be 
layered on top of it. Or am I wrong?

An example : We've got some developers here who are starting to get into 
XML development, and I've fielded a few questions - particularly 
regarding well-formedness, validity, and the DOM API. The first 
two were relatively easy to answer. Most of the rest of the 
confusion seemed to be at the (DOM) API level - these developers have 
been given an XML message format spec (which doesn't use any 
XML nastiness) and just need to start writing some code 
against it.

So this leads me to the conclusion that a simplified API, perhaps 
coupled with a means to define the XML feature subset of a schema 
would address 99% of the issues raised thus far.

But I keep getting the niggly feeling that I'm missing something.

Any comments?

L.

==================================================================
    "Never Do With More, What Can Be Achieved With Less"
				---William of Occam
==================================================================
Leigh Dodds                             Eml:  ldodds@ingenta.com
ingenta ltd                             Tel:  +44 1225 826619
BUCS Building, University of Bath       Fax:  +44 1225 826283

HomePage :				 	http://www.bath.ac.uk/~ccslrd/
WebLog   :			     http://weblogs.userland.com/eclectic/
==================================================================


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 11:29:39 1999
From: murata.makoto at fujixerox.co.jp (MURATA Makoto)
Date: Mon Jun  7 17:17:07 2004
Subject: Fwd: Announcement of draft-murata-xml-01.txt
Message-ID: <199911171131.AA03208@archlute.fujixerox.co.jp>

MURATA Makoto wrote:
> Simon St. Laurent and I co-authored an I-D for XML media types.  It 
> is available at:
> 
> 	http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt
> 
> On the basis of discussion in this ML (most notably Ned's comments),
> this version shows when text/xml is more appropriate than application/xml 
> and vice versa.  Non-XPointer fragment identifiers for XML vocabularies 
> like SVG and SMIL requires further discussion.
> 
> Incidentally, the XSLT recommendation is published from W3C today.  It is 
> available at:
> 
> 	http://www.w3.org/TR/xslt
> 
> Although we have agreed that fragments do not have media types, "2.7 Embedding 
> Stylesheets" of this recommendation uses "text/xml" for fragments.  Since another 
> recommendation of W3C, namely "Associating stylesheets with XML documents", 
> already mandates the pseudo attribute "type" for stylesheet-linking PIs, 
> XSLT had to specify something.  Comments?
> 
> Cheers,
> 
> Makoto
>  
> Fuji Xerox Information Systems
>  
> Tel: +81-44-812-7230   Fax: +81-44-812-7231
> E-mail: murata.makoto@fujixerox.co.jp
> 

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jjc at jclark.com  Wed Nov 17 12:02:26 1999
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:17:07 2004
Subject: Parser compliance
References: <Pine.LNX.4.10.9911170932510.13216-100000@localhost.localdomain>
Message-ID: <38329723.E369F331@jclark.com>

Richard Lanyon wrote:
> 
> On 16 Nov 1999, David Megginson wrote:
> > Sean Mc Grath <digitome@iol.ie> writes:
> 
> > > Does anyone knowledgeable in the minutia of XML compliance care to
> > > list the extant parsers and put them into fully XML 1.0 compliant
> > > and non-XML 1.0 compliant camps?
> 
> > Well, Expat is drop-dead, shoot-your-dog-if-it-ain't conformant...
> 
> Indeed, but it's not necessarily "fully-featured" in that it doesn't
> include external entities

It does actually. It's supported external general entities for a long
time.  The current test version (at
ftp://ftp.jclark.com/pub/test/expat.zip) also support external parameter
entities including the DTD subset; this is the version being used in
Perl or Mozilla, so it's actually fairly solid.

> and isn't validating

This is true.  XML 1.0 DTD validation isn't very useful for the things
I'm interested in and I want to keep the code size small.  Expat
provides enough information that you could implement a validation layer
on top.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sb at metis.no  Wed Nov 17 12:24:40 1999
From: sb at metis.no (Steinar Bang)
Date: Mon Jun  7 17:17:07 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: "James Tauber"'s message of "Wed, 17 Nov 1999 06:04:34 -0500"
References: <wh66z1h65x.fsf@viffer.oslo.metis.no> <007501bf30eb$88acd860$eb020a0a@bowstreet.com>
Message-ID: <whogcte26c.fsf@viffer.oslo.metis.no>

>>>>> "James Tauber" <jtauber@jtauber.com>:

> UTF-8 and UTF-16 are transformations formats of ISO10646, not
> Unicode.

Aren't Unicode and ISO 10646 pretty much one and the same these days?
At least that's how I read:
        <URL:http://www.unicode.org/unicode/faq/#Unicode and ISO 10646>

> UTF-8 gives access to all 2^31 characters from the UCS repertoire.

> UTF-16, however, only gives access to the equivalent of Unicode with the
> surrogate extension mechanism, ie the first 17 planes of the UCS.

Not sure if I understand the UTF-16 bit above, but I'm reading this:
        <URL:http://www.unicode.org/unicode/faq/#UTF-16 and UCS-4>
to UTF-16 being able to represent the full UCS-4, which is what you
say UTF-8 can do, if I interpret you correctly...?


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



From rgl at decisionsoft.com  Wed Nov 17 12:30:12 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:07 2004
Subject: Parser compliance
In-Reply-To: <38329723.E369F331@jclark.com>
Message-ID: <Pine.LNX.4.10.9911171221510.13799-100000@localhost.localdomain>

On Wed, 17 Nov 1999, James Clark wrote:
> Richard Lanyon wrote:
> > On 16 Nov 1999, David Megginson wrote:

> > > Well, Expat is drop-dead, shoot-your-dog-if-it-ain't conformant...

> > Indeed, but it's not necessarily "fully-featured" in that it doesn't
> > include external entities

> It does actually. It's supported external general entities for a long
> time.  The current test version (at
> ftp://ftp.jclark.com/pub/test/expat.zip) also support external parameter
> entities including the DTD subset; this is the version being used in
> Perl or Mozilla, so it's actually fairly solid.

Ah, right - apologies for disseminating false information, I was going on
"received wisdom" which is always an error in the Age of Internet Time.

> > and isn't validating

> This is true.  XML 1.0 DTD validation isn't very useful for the things
> I'm interested in and I want to keep the code size small.

It's not useful for our processing, either, but it's possible that some
people might want our processor to tell them what's wrong with their XML
before processing it.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


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



From nisse at lysator.liu.se  Wed Nov 17 13:38:16 1999
From: nisse at lysator.liu.se (Niels Möller)
Date: Mon Jun  7 17:17:07 2004
Subject: Parser compliance
In-Reply-To: James Clark's message of "Wed, 17 Nov 1999 18:53:07 +0700"
References: <Pine.LNX.4.10.9911170932510.13216-100000@localhost.localdomain> <38329723.E369F331@jclark.com>
Message-ID: <nnn1sd2q83.fsf@sanna.lysator.liu.se>

James Clark <jjc@jclark.com> writes:

> > and isn't validating
> 
> This is true.  XML 1.0 DTD validation isn't very useful for the things
> I'm interested in and I want to keep the code size small.  Expat
> provides enough information that you could implement a validation layer
> on top.

I have a question on expat's API. Say that one of the callback
function detects some error (e.g. unexpected element name or
attribute) and wants the entire parse to fail. How do I report this
back? To me, the natural way to do it would be to have the callback
function return an error code to the parser, which can then clean up,
stop parsing, and pass the error code on to the caler. But callback
functions return void, so that's obviously not how it is supposed to
work.

/Niels




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



From Wdehora at cromwellmedia.co.uk  Wed Nov 17 13:54:42 1999
From: Wdehora at cromwellmedia.co.uk (Bill dehOra)
Date: Mon Jun  7 17:17:08 2004
Subject: Feeling good about SML
Message-ID: <AA4C152BA2F9D211B9DD0008C79F760A5CA3AE@odin.cromwellmedia.co.uk>

Don,

Suggestions:

First define the environment, or domain, that SML is targeted for. Inversely
one could define what XML isn't for. Then rephrase all specifications in
terms of the domain, mentioning XML if necessary. This may allow specs to
become more operational and verifiable. Possibly:

1. SML shall be targeted for the following domains: [TBD]
2. SML shall be a simplified subset of XML.
3. SML shall have no optional features.
4. SML shall be designed with ease of implementation in mind.
5. XML implementations shall understand SML. (implicit by 2?)


Regards,

Bill de hOra



        

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



From richard at cogsci.ed.ac.uk  Wed Nov 17 14:01:51 1999
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:17:08 2004
Subject: Parser compliance
In-Reply-To: Richard Lanyon's message of Wed, 17 Nov 1999 09:41:13 +0000 (GMT)
Message-ID: <9820.199911171401@doyle.cogsci.ed.ac.uk>

> One parser which does do these things is LT XML, but that isn't
> very fussy about badly-formed XML (for a start, it doesn't reject
> documents with more than one top-level element).

LT XML has a flag (NSL_read_strict in the library; -x option to
xmlnorm) which enforces the few XML constraints that are (for
historical reasons) not enabled by default.

Any errors that aren't detected in strict mode should be considered
bugs and reported to me.

LT XML's underlying parser, RXP, is available separately and also
provides namespace support and checking, which is not in LT XML yet.

For more information on RXP and LT XML, see

  http://www.ltg.ed.ac.uk/software/

There is a web page that lets you check documents for well-formedness
and optionally validity and namespace-correctness using RXP at

  http://www.ltg.ed.ac.uk/~richard/xml-check.html

-- Richard

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 14:13:14 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:08 2004
Subject: Parser compliance
In-Reply-To: <m3yabxkihd.fsf@localhost.localdomain>
References: <Sean Mc Grath's message of "Tue, 16 Nov 1999 17:36:19 +0000">
 <3.0.6.32.19991116173619.0092d320@gpo.iol.ie>
Message-ID: <3.0.6.32.19991117140109.0092f8c0@gpo.iol.ie>

Thanks to Dave Megginson for his list. I would appreciate
it if knowledgable people help fill in the blanks below.

I believe there is real merit in this exercise. In
particular, I believe us system integrator types have a lot
to learn from the NOTEs that will hopefully adorn
this table.

The completed version of this table should be
on the Web somewhere.


Fully 1.0 Compliant - Non Validating
-------------------------------------
1. Expat (As used in Perl, Python, Tcl, Ruby, C and C++ apps)

NOTE: Expat does Unicode but that does not
mean that the host language - e.g. Python, C -
had native support for Unicode.

2. XT


Fully XML 1.0 Compliant - Validating
------------------------------------


Non XML 1.0 Compliant - Non-Validating
--------------------------------------
nsgmls (C++)
xmlproc (Python)


Non XML 1.0 Compliant - Validating
----------------------------------
nsgmls (C++)
xmlproc (Python)




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



From pandeng at telepath.com  Wed Nov 17 14:32:16 1999
From: pandeng at telepath.com (Steve Schafer)
Date: Mon Jun  7 17:17:08 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: <whogcte26c.fsf@viffer.oslo.metis.no>
References: <wh66z1h65x.fsf@viffer.oslo.metis.no> <007501bf30eb$88acd860$eb020a0a@bowstreet.com> <whogcte26c.fsf@viffer.oslo.metis.no>
Message-ID: <3834bbba.32104999@90.0.0.40>

On 17 Nov 1999 13:24:27 +0100, you wrote:

>Not sure if I understand the UTF-16 bit above, but I'm reading this:
>        <URL:http://www.unicode.org/unicode/faq/#UTF-16 and UCS-4>
>to UTF-16 being able to represent the full UCS-4, which is what you
>say UTF-8 can do, if I interpret you correctly...?

Section C.3 of the Unicode 2.0 spec, paragraph 4:

"UTF-16 does not support the representation of all the UCS-4 code
space but is limited to the BMP and the next 16 planes...."

-Steve Schafer


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Wed Nov 17 14:54:41 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:08 2004
Subject: (My) Feeling About SML
References: <000801bf30eb$0141cac0$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <007d01bf310a$3f266ca0$f9d18dce@WORKGROUP>


----- Original Message -----
From: Leigh Dodds <ldodds@ingenta.com>
To: xml-dev <xml-dev@ic.ac.uk>
Sent: Wednesday, November 17, 1999 6:00 AM
Subject: (My) Feeling About SML


>
> So this leads me to the conclusion that a simplified API, perhaps
> coupled with a means to define the XML feature subset of a schema
> would address 99% of the issues raised thus far.

I agree.  I'm *interested* in "SML" for small devices and high throughput
devices, but I agree that the speed/size benefits for processors of
stripping down the spec remains to be proved.  I just want to see some
evidence before dismissing the possibility.

My main interest here is in stripping down the DOM API for small devices.
We *know* that many of the features apply mostly to browsers and are
overkill for servers, PDAs, etc.  Of course the DOM WG or somebody else
could define a "SDOM" API . The problem is that without guidance from some
"SML" spec, it's not at all clear what interfaces to remove.  Should, for
example,  the DOM WG (or the SDOM Mafia, or whoever) just decide on their
own that external parsed entities are "evil" and should not be supported in
"SDOM"?  There's clearly no way for the API used by a message receiver to
control or even negotiate the set of XML features used by the sender.  So an
"SDOM" API without some spec or meta-spec defining the subset of XML to
employ is not likely to be terribly useful.

But, as you say, if there was a means to define the XML feature subset, as
an add-on to the XML spec rather than a separate "SML" spec, then various
"SDOM" activities could go forward by simply deciding on the feature subset
that a particular API would support.

So, we NEED stripped down DOM-like APIs for small and high-throughput
platforms ... a formal means to define an XML feature subset would help
specify when the stripped down APIs are appropriate. There *may* also be an
overall speed benefit for the stripped down processors handling the
stripped-down XML subsets, but this remains to be proven.

Mike Champion

(p.s. OK, we don't "need" DOM-like APIs, we could use SAX ... but many of us
find the DOM abstractions to be more useful.  Also, there's a new generation
of tools to generate Java or C++ classes directly from schemas that further
abstract the API from the XML data.  It's not clear to me whether these will
have to wrestle with the SML issues or whether, for example, the lack of
entity declarations in a DTD will imply that no entity resolving code is
generated ... in any event, I think a formal XML feature subset mechanism
would simplify these code generation tools as well as the DOM-like APIs.)


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



From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Nov 17 14:56:37 1999
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon Jun  7 17:17:08 2004
Subject: Parser compliance
In-Reply-To: <3.0.6.32.19991117140109.0092f8c0@gpo.iol.ie>
References: <Sean Mc Grath's message of "Tue, 16 Nov 1999 17:36:19 +0000">
	<3.0.6.32.19991116173619.0092d320@gpo.iol.ie>
	<3.0.6.32.19991117140109.0092f8c0@gpo.iol.ie>
Message-ID: <14386.49545.809454.247811@spqr.oucs.ox.ac.uk>

Sean Mc Grath writes:
 > Fully 1.0 Compliant - Non Validating
...
 > 2. XT
 > 
XT is not an XML parser. It uses XP. 

Sebastian


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



From mbrady at nist.gov  Wed Nov 17 15:11:11 1999
From: mbrady at nist.gov (Mary Brady)
Date: Mon Jun  7 17:17:08 2004
Subject: Parser compliance
In-Reply-To: <38325CA8.709B2F05@eng.sun.com>
Message-ID: <NDBBJOKMCLKFDICNAEMBCEAICAAA.mbrady@nist.gov>

The OASIS XML Conformance Subcommittee released a draft
test suite last July.  It contains over 1000 XML tests
that can be used to test conformance to the XML 1.0
Recommendation.  These tests are publicly available
from
	http://www.oasis-open.org/committees/xmltest/testsuite.htm

Dave Brownell took this test suite, developed a driver that ran the
tests through a variety of current parsers, and published the results
on XML.COM.  I don't have the url handy (XML.COM seems to be down
at the moment), but if you go to XML.COM and
search for "conformance", you can find the article.  It gives both
and summary and detailed info on many different xml processors.

With a little effort, his driver could be extended to cover
additional processors.

In addition, the test suite is also pointed to from the NIST web
site,
	http://www.nist.gov/xml/

NIST has also developed a set of DOM Level 1 tests for the
ECMAScript binding.  Tests are currently available for
ECMAScript Fundamental and Extended, and within the week,
will be available for HTML.  In all, there will be close
to 1000 tests here as well.  This test suite currently
runs in IE5, and we are working on getting it to run in
Mozilla M10.  We are also developing an equivalent set of
tests for the Java binding.

Both test suites are publicly available.  Feel free to use them
to test your implementations.  If you have any additional tests
to add to the test suite, please let us know.

Mary Brady
mbrady@nist.gov
NIST, Conformance Testing
Chair, OASIS XML Conformance Subcommittee


-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
James Duncan Davidson
Sent: Wednesday, November 17, 1999 2:44 AM
To: David Megginson
Cc: xml-dev@ic.ac.uk
Subject: Re: Parser compliance




> Likewise, David
> Brownell is pretty fierce about conformance, so I imagine that Sun's
> XML library (which he wrote before he left Sun) is pretty much on the
> money.

And the folks working on the Sun parser are still fierce about
conformance as I've been finding out. :) Even as we move to working more
and more with the xml.apache.org project, we'll continue to be fierce
about it.

.duncan


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



From gkholman at CraneSoftwrights.com  Wed Nov 17 15:25:14 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:17:08 2004
Subject: Parameter Entity Replacement and the XML 1.0 Grammar
Message-ID: <4.2.0.58.19991117100310.00bf82c0@pop1.attglobal.net>

Hi folks!

Down below I have an example extrapolated from working markup I've been 
using with XT for months.

To parameterize my production environment, I use parameter entities quite a 
bit, as you can see in the file "test.ent".

XT has been accepting this declaration of NDATA entities, giving me the 
equivalent as if the replacement values were correctly replaced.

Today I started using a validating parser on the source file and it is 
choking on the entity declaration.

I immediately thought the new parser I was using was at fault, but thought 
I'd check XML 1.0 and saw that perhaps parameter entity references are not 
allowed according to the grammar:

[71] GEDecl ::= '<!ENTITY' S Name S EntityDef S? '>'

[73] EntityDef ::= EntityValue | (ExternalID NDataDecl?)

[75] ExternalID ::= 'SYSTEM' S SystemLiteral

[11] SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'")

[76] NDataDecl ::= S 'NDATA' S Name

[5] Name ::= (Letter | '_' | ':') (NameChar)*

[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | 
Extender


But .... according to 4.4.8 parameter entity references can wholly replace 
integral grammatical tokens, so perhaps the use of parameter entity 
references is *outside* the grammar productions of XML 1.0.

So, my question is:  Does 4.4.8 take precedence over the grammar 
productions (the new parser is incorrect), or is the behaviour I am used to 
not correct (XT is incorrect)?

My belief is I've been working properly all along, XT is correct, and the 
new parser is incorrect.

Thanks for any help you can be.

............. Ken

T:\ftemp>type test.xml
<?xml version="1.0"?>
<!DOCTYPE doc [
<!ELEMENT doc EMPTY>
<!ATTLIST doc file ENTITY #REQUIRED>
<!ENTITY % test SYSTEM "test.ent">
%test;
]><doc file="abc"/>
T:\ftemp>type test.ent
<!ENTITY % e "wmf"><!--non .gif extension-->
<!NOTATION %e; SYSTEM "">
<!ENTITY % filename "'abc.%e;'">
<!ENTITY abc SYSTEM %filename; NDATA %e;>
<!--end of file-->
T:\ftemp>type test.xsl
<?xml version="1.0"?>
<!DOCTYPE xsl:stylesheet []>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 version="1.0">

<xsl:output method="text"/>

<xsl:template match="/doc">
   Value is: <xsl:value-of select="unparsed-entity-uri(@file)"/>
</xsl:template>

</xsl:stylesheet>

T:\ftemp>xt test.xml test.xsl test.txt

T:\ftemp>type test.txt

   Value is: file:/T:/ftemp/abc.wmf
T:\ftemp>call xml test.xml
Parsing: 'test.xml' for XML errors
[Fatal Error] test.ent:4:21: The system identifier must begin with either a 
single or double quote character.

T:\ftemp>



--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 15:34:18 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:08 2004
Subject: Towards an XML Parser Compliance Table Version:17-11-99-15:16
Message-ID: <3.0.6.32.19991117152150.008efe80@gpo.iol.ie>

XML Experts (especially XML parser implementors),

Please help fill in this table.

Fully 1.0 Compliant - Non Validating
-------------------------------------
1. Expat (As used in Perl, Python, Tcl, Ruby, C and C++ apps)

NOTE: Expat does Unicode but that does not
mean that the host language - e.g. Python, C -
has native support for Unicode.

2. XP

3. RXP

NOTE: Available stand-alone and also as underlying parser
used in LT XML. Has a flag (NSL_read_strict in the library;
-x option to xmlnorm) which enforces the few XML constraints
that are not enabled by default.


Fully XML 1.0 Compliant - Validating
------------------------------------
1. RXP

NOTE:
Available stand-alone and also as underlying parser used
in LT XML. Has a flag (NSL_read_strict in the library;
-x option to xmlnorm) which enforces the few XML
constraints that are not enabled by default.


Non XML 1.0 Compliant - Non-Validating
--------------------------------------
nsgmls (C++)
xmlproc (Python)


Non XML 1.0 Compliant - Validating
----------------------------------
nsgmls (C++)
xmlproc (Python)




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



From robin at isogen.com  Wed Nov 17 15:52:44 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:08 2004
Subject: Parser compliance
In-Reply-To: <NDBBJOKMCLKFDICNAEMBCEAICAAA.mbrady@nist.gov>
Message-ID: <Pine.GSO.3.96.991117094903.17627Q-100000@grind>

I try to keep some links updated in:

  "XML Conformance"

  http://www.oasis-open.org/cover/xmlConformance.html

- robin

----------------------------------------------------------

On Wed, 17 Nov 1999, Mary Brady wrote:

> The OASIS XML Conformance Subcommittee released a draft
> test suite last July.  It contains over 1000 XML tests
> that can be used to test conformance to the XML 1.0
> Recommendation.  These tests are publicly available
> from
> 	http://www.oasis-open.org/committees/xmltest/testsuite.htm
> 
> Dave Brownell took this test suite, developed a driver that ran the
> tests through a variety of current parsers, and published the results
> on XML.COM.  I don't have the url handy (XML.COM seems to be down
> at the moment), but if you go to XML.COM and
> search for "conformance", you can find the article.  It gives both
> and summary and detailed info on many different xml processors.
> 
> With a little effort, his driver could be extended to cover
> additional processors.
> 
> In addition, the test suite is also pointed to from the NIST web
> site,
> 	http://www.nist.gov/xml/
> 
> NIST has also developed a set of DOM Level 1 tests for the
> ECMAScript binding.  Tests are currently available for
> ECMAScript Fundamental and Extended, and within the week,
> will be available for HTML.  In all, there will be close
> to 1000 tests here as well.  This test suite currently
> runs in IE5, and we are working on getting it to run in
> Mozilla M10.  We are also developing an equivalent set of
> tests for the Java binding.
> 
> Both test suites are publicly available.  Feel free to use them
> to test your implementations.  If you have any additional tests
> to add to the test suite, please let us know.
> 
> Mary Brady
> mbrady@nist.gov
> NIST, Conformance Testing
> Chair, OASIS XML Conformance Subcommittee
> 
> 
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> James Duncan Davidson
> Sent: Wednesday, November 17, 1999 2:44 AM
> To: David Megginson
> Cc: xml-dev@ic.ac.uk
> Subject: Re: Parser compliance
> 
> 
> 
> 
> > Likewise, David
> > Brownell is pretty fierce about conformance, so I imagine that Sun's
> > XML library (which he wrote before he left Sun) is pretty much on the
> > money.
> 
> And the folks working on the Sun parser are still fierce about
> conformance as I've been finding out. :) Even as we move to working more
> and more with the xml.apache.org project, we'll continue to be fierce
> about it.
> 
> .duncan
> 
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
> 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 15:53:18 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:17:08 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: <3834bbba.32104999@90.0.0.40>
References: <wh66z1h65x.fsf@viffer.oslo.metis.no>
	<007501bf30eb$88acd860$eb020a0a@bowstreet.com>
	<whogcte26c.fsf@viffer.oslo.metis.no>
	<3834bbba.32104999@90.0.0.40>
Message-ID: <14386.49420.450000.495311@menteith.com>

At 17 Nov 1999 14:29 GMT, Steve Schafer wrote:
 > On 17 Nov 1999 13:24:27 +0100, you wrote:
 > 
 > >Not sure if I understand the UTF-16 bit above, but I'm reading this:
 > >        <URL:http://www.unicode.org/unicode/faq/#UTF-16 and UCS-4>
 > >to UTF-16 being able to represent the full UCS-4, which is what you
 > >say UTF-8 can do, if I interpret you correctly...?
 > 
 > Section C.3 of the Unicode 2.0 spec, paragraph 4:
 > 
 > "UTF-16 does not support the representation of all the UCS-4 code
 > space but is limited to the BMP and the next 16 planes...."

True, but that's more code values than anybody expects to ever
standardise (although that's the opinion of the same people that
thought that they'd never need more than the BMP).

All of the currently defined Unicode and ISO/IEC 10646 characters
(both people define the same characters) are in the BMP.  It won't be
long until characters are defined in Plane 1 and Plane 2 (with
possible spill-over into Plane 3), plus planes 15 and 16 are reserved
for private use.

Currently the only thing defined for the characters beyond Plane 16 of
Group 00 (i.e. beyond the characters addressable with UTF-16) are more
areas available for private use.

The fuss over UTF-8 or UTF-16 is over the number of bytes used to
represent the characters in the BMP, i.e. the currently defined
characters.  UTF-16 uses two bytes per character, and UTF-8 uses one
byte per character for the ASCII characters, two bytes per character
for not that many more characters, and three bytes per character for
most of the characters in the BMP.  Both UTF-8 and UTF-16 use four
bytes per character to represent the characters in planes 1 to 16.

(There's also UTF-32, which is four bytes per character for all the
characters that you can represent with UTF-16.)

UTF-8 is efficient if you use a lot of ASCII, e.g. if you're an
English speaker and all you use is ASCII, but it's more bytes per
character than UTF-16 for a whole lot of other scripts (plus it's more
bytes per character than an lot of current script-specific encodings).

So the issue isn't how many characters the different encodings can
represent, but how efficiently (or how uniformly) they represent the
currently defined characters.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From nhs at llnl.gov  Wed Nov 17 16:17:10 1999
From: nhs at llnl.gov (Norman H. Samuelson)
Date: Mon Jun  7 17:17:08 2004
Subject: DTD Question - PCDATA followed by an optional element
Message-ID: <4.2.0.58.19991117080318.00a76b20@popeye.llnl.gov>

I have a large number of fields that normally hold simple textual data, but 
might also include a comment.  The XML would look like this with no comment:

   <rho0> 1.0 </rho0>

or this, when the comment is present:

   <rho0> 1.0 <comment> blah, blah </comment> </rho0>

I have no problem in the DTD when I leave out the possibility of a comment, 
I simply use something like this:

   <!ELEMENT rho0 (#PCDATA)>

To include the comment, I would like to be able to simply say:

   <!ELEMENT comment (#PCDATA)>
   <!ELEMENT rho0 (#PCDATA, comment?)>

That doesn't seem to be acceptable.  I also tried:

   <!ELEMENT rho0 ((#PCDATA) | (#PCDATA, comment))>

Is it possible to do what I want?

If not, I could consider putting one more level of tags around the data, 
like this:

   <rho0> <data> 1.0 </data> <comment> blah, blah </comment> </rho0>

But that adds extra bulk, and code, that should not be needed.  Any 
suggestions would be appreciated.

Whatever solution I come up with must work with IBM's XML4J parser.


- Norm -

Norman H. Samuelson                  nhs@llnl.gov
Lawrence Livermore National Lab      925-422-0661
P.O. Box 808, L-98
Livermore, CA 94551 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 16:50:26 1999
From: schen at falconwing.com (schen@falconwing.com)
Date: Mon Jun  7 17:17:08 2004
Subject: Towards an XML Parser Compliance Table Version:17-11-99-15:16
In-Reply-To: <3.0.6.32.19991117152150.008efe80@gpo.iol.ie>
Message-ID: <Pine.LNX.3.96.991117113240.5565A-100000@www.falconwing.com>

Hi Sean, everyone,

David Brownell already wrote up a nice article about this at:
http://www.xml.com/pub/1999/09/conformance/index.html
which I can't get to at the moment.

His test driver can be found at http://home.pacbell.net/david-b/xml/

>From memory:

On Wed, 17 Nov 1999, Sean Mc Grath wrote:

> Fully 1.0 Compliant - Non Validating
> -------------------------------------
4. Sun ProjectX

> Fully XML 1.0 Compliant - Validating
> ------------------------------------
2. Sun ProjectX

> Non XML 1.0 Compliant - Non-Validating
> --------------------------------------
aelfred
DataChannel
Microsoft
IBM XML4J
IBM XML4C


> Non XML 1.0 Compliant - Validating
> ----------------------------------
> nsgmls (C++)
> xmlproc (Python)

IBM XML4J
IBM XML4C (? I think)

-------------
BTW, I think a more useful table would include what other features the
parsers have, rather than just a strict compliance/validating judgement.

Example features to consider would be: parser size (why I use aelfred),
parser speed (why XP is a good choice), language supported (Java/C/C++),
DOM1 support, DOM2 support, SAX support, SAX2 support, namespace support,
external entities support, memory usage, maximum file size supported,
and last but not least character set encodings supported.

(Note that there are add-on utilities to graft DOM and SAX2 support to
various popular parsers too)

. . . Sean (not related =)



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



From richard at cogsci.ed.ac.uk  Wed Nov 17 16:47:41 1999
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:17:08 2004
Subject: DTD Question - PCDATA followed by an optional element
In-Reply-To: Norman H. Samuelson's message of Wed, 17 Nov 1999 08:16:53 -0600
Message-ID: <199911171647.QAA08123@rhymer.cogsci.ed.ac.uk>

> I have a large number of fields that normally hold simple textual data, but 
> might also include a comment.

You can't constrain the content in that way with a DTD.  The best you
do is

    <!ELEMENT rho0 (#PCDATA|comment)*>

which allows any mixture of comments and text.

The only alternative is to change the structure, perhaps as you
suggest by putting the data in another element, or perhaps by
making the comment into an attribute.

-- Richard

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 17:28:38 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:09 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
Message-ID: <3.0.32.19991117092816.0152e5f0@pop.intergate.ca>

At 06:04 AM 11/17/99 -0500, James Tauber wrote:
>UTF-16, however, only gives access to the equivalent of Unicode with the
>surrogate extension mechanism, ie the first 17 planes of the UCS.

Right, a mere million extra characters in excess of what we're using now.

This feels like a pretty low-risk option to me.  

In terms of actual usability, there's effectively no difference between
UTF-16 and UTF-8.  UTF-16 seems to be an easier sell in Japan for reasons
that I've not fully understood.

What's really happening, near as I can tell, is that C programmers use
UTF-8 and Java programmers use UTF-16, regardless of where they're from.

Fortunately, this particular conversion is easy and requires no tables. -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 17:39:54 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:09 2004
Subject: Parser compliance
Message-ID: <3.0.32.19991117093112.01aad530@pop.intergate.ca>

At 12:30 PM 11/17/99 +0000, Richard Lanyon wrote:
>On Wed, 17 Nov 1999, James Clark wrote:
>> XML 1.0 DTD validation isn't very useful for the things
>> I'm interested in and I want to keep the code size small.
>
>It's not useful for our processing, either, but it's possible that some
>people might want our processor to tell them what's wrong with their XML
>before processing it.

I have often wondered where this myth arose that validating against a DTD
will tell you, in useful real-world terms, "what's wrong with your XML".

 -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 17:43:17 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:09 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: <wh66z1h65x.fsf@viffer.oslo.metis.no>
Message-ID: <Pine.GSU.4.10.9911170940260.8895-100000@netcom3.netcom.com>

On 17 Nov 1999, Steinar Bang wrote:

> >>>>> "Don Park" <donpark@docuverse.com>:
> 
> > I was born in Korea so I appreciate your position.  However, your
> > opposition of SML is based on the assumption that SML will only
> > support UTF-8.  The list of SML features is preliminary and,
> > personally, I do not mind seeing SML support both UTF-8 and UTF-16
> > although not necessarily at the same time since the application
> > might require either encoding but not both.
> 
> Er... AFAIK you can represent the exactly the same characters in UTF-8
> and UTF-16, since both are transformation formats of the full 32 bit
> Unicode.  Maybe I'm missing something here...?

I think his point was that UTF-8 imposes a 50% size penalty over UTF-16
for typical CJKV text.



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



From BBerck at ESPS.com  Wed Nov 17 17:50:10 1999
From: BBerck at ESPS.com (Ben Berck)
Date: Mon Jun  7 17:17:09 2004
Subject: Grafting DOM on a C++ XML parser?
Message-ID: <4139ED560536D3118F100008C7F36E451A8D4A@HQMAIL>

Sean of FalconWing wrote:
>>(Note that there are add-on utilities to graft DOM and SAX2 support to
>>various popular parsers too)

We have been burnt with relying on MSXML.DLL, so we have chosen Dundas
Software's new C++ XML parser, which includes source code.  However, I was
disappointed to see that it doesn't support XML DOM.

What add-on utility exists to get the DOM on top of a C++ XML Parser class?

Thanks,
Ben Berck


-----Original Message-----
From: schen@falconwing.com [mailto:schen@falconwing.com]
Sent: Wednesday, November 17, 1999 11:42 AM
To: Sean Mc Grath
Cc: xml-dev@ic.ac.uk
Subject: Re: Towards an XML Parser Compliance Table
Version:17-11-99-15:16


Hi Sean, everyone,

David Brownell already wrote up a nice article about this at:
http://www.xml.com/pub/1999/09/conformance/index.html
which I can't get to at the moment.

His test driver can be found at http://home.pacbell.net/david-b/xml/

>From memory:

On Wed, 17 Nov 1999, Sean Mc Grath wrote:

> Fully 1.0 Compliant - Non Validating
> -------------------------------------
4. Sun ProjectX

> Fully XML 1.0 Compliant - Validating
> ------------------------------------
2. Sun ProjectX

> Non XML 1.0 Compliant - Non-Validating
> --------------------------------------
aelfred
DataChannel
Microsoft
IBM XML4J
IBM XML4C


> Non XML 1.0 Compliant - Validating
> ----------------------------------
> nsgmls (C++)
> xmlproc (Python)

IBM XML4J
IBM XML4C (? I think)

-------------
BTW, I think a more useful table would include what other features the
parsers have, rather than just a strict compliance/validating judgement.

Example features to consider would be: parser size (why I use aelfred),
parser speed (why XP is a good choice), language supported (Java/C/C++),
DOM1 support, DOM2 support, SAX support, SAX2 support, namespace support,
external entities support, memory usage, maximum file size supported,
and last but not least character set encodings supported.

. . . Sean (not related =)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991117/010f22d7/attachment.htm
From david-b at pacbell.net  Wed Nov 17 18:00:17 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:09 2004
Subject: Parser compliance
References: <3.0.6.32.19991116173619.0092d320@gpo.iol.ie> <m3yabxkihd.fsf@localhost.localdomain>
Message-ID: <3832ED20.979408A8@pacbell.net>

David Megginson wrote:
> 
> 	 I know that OASIS has been working on a
> general conformance test suite -- it might also be nice if XML Dev'ers
> put some of their energy into a SAX conformance test suite.

Mary Brady had a good note about what OASIS (and NIST) are doing,
and other posts have mentioned some of the additional work I did
and reported in this article:

    http://www.xml.com/pub/1999/09/conformance/index.html

Accessible through that article is the SAX test harness which
supports it.  It's open source.  Any updates will be at:

    http://home.pacbell.net/david-b/xml/

Please, anyone thinking of a SAX conformance test suite:  look at
that first, and think carefully about whether another one is needed.
I'll gladly accept feedback.  I certainly worked to avoid bugs, and
none have yet been reported to me.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From keshlam at us.ibm.com  Wed Nov 17 18:01:05 1999
From: keshlam at us.ibm.com (Joseph Kesselman (yclept Keshlam))
Date: Mon Jun  7 17:17:09 2004
Subject: Announce: IBM XSL Editor
Message-ID: <3832ECDF.1E2D9AE5@us.ibm.com>

Timely assistance for those who want to take advantage of
the new W3C Recommendation status of XSLT:

The IBM XSL Editor application allows a user to import,
create, and save Extensible  Stylesheet Language (XSL) style
sheets and Extensible Markup Language (XML) source
documents.

This XSL stylesheet editor incorporates trace function and
provides assistance with writing select and match
expressions. It integrates XSL Trace with the Visual
Transform tool, both available on alphaWorks. 

IBM's XSL Editor allows users to set and remove "break
points" on the style sheet and source document. The XSL
Editor user interface features an XML "source based"
collapsible "tree view" with dynamic font resizing for
"Zooming" in/out to handle small/large documents. Dynamic
"edit pads" provide a vehicle for style sheet and source
document editing that are automatically kept in synch with
their corresponding tree views. Style sheet authoring is
made convenient by the ability to automatically generate
XPath syntax from sample source documents.

For more information and downloadable code:
http://www.alphaWorks.ibm.com/tech/xsleditor 

-- 
-----------------------------------------------------------------
Joe Kesselman, keshlam@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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 18:05:47 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:09 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: <3.0.32.19991117092816.0152e5f0@pop.intergate.ca>
Message-ID: <Pine.GSU.4.10.9911171002300.8895-100000@netcom3.netcom.com>

On Wed, 17 Nov 1999, Tim Bray wrote:

> In terms of actual usability, there's effectively no difference between
> UTF-16 and UTF-8.  UTF-16 seems to be an easier sell in Japan for reasons
> that I've not fully understood.

Could that have something to do with the fact that Japanese characters
require two octets in UTF-16 and three in UTF-8?



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



From kragen at pobox.com  Wed Nov 17 18:09:58 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:17:09 2004
Subject: UTF-8 vs UTF-16...?
Message-ID: <Pine.GSO.4.10.9911171258250.23095-100000@kirk.dnaco.net>

According to the latest Unicode book (is it version 2.0?  Or 3.0?)
UTF-8 does not allow you to encode more than the first 17 planes of ISO
10646.  If I remember correctly, the formats are (omitting leading
output zero bits):

one byte:
0xxxxxxx -> xxxxxxx
two bytes:
110yyyyy 10xxxxxx -> yyy yyxxxxxx
three bytes:
1110zzzz 10yyyyyy 10xxxxxx -> zzzzyyyy yyxxxxxx
four bytes:
11110uuu 10uuzzzz 10yyyyyy 10xxxxxx -> wwwww zzzzyyyy yyxxxxxx
where wwwww is uuuu+1.  (These characters are encoded with surrogate
pairs in UTF-16.)  I may be mistaken about this one; my book is at home.

No five-byte or longer sequences are listed.  No valid sequences
starting with more than four ones are listed.  Presumably these two
omissions correspond, and an extended UTF-8 with these additions would
allow you to handle larger character sets.

It may be that other standards actually specify such an extended UTF-8.

So "bigger character range" is probably not a valid reason for wanting
to use UTF-8 -- quite aside from the question of whether you really
need more than the million or so characters UTF-16 can encode --
because UTF-8 decoders implemented according to Unicode's spec will
choke if you try to encode bigger characters in it.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 18:47:09 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:09 2004
Subject: Feeling good about SML
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E9073@sohos002.ied-support.net>

Hi everyone,

Just a quick note. My mum kept having a mental block when it came to
understanding non-skid braking mechanisms. Try as I could, I couldn't
get her to understand them, so in the end I thought the best thing for
it was to remove the brakes from the car all together.

Solved a lot of problems.

And related to the SML non-debate, I just read that Samsung are bringing
out a phone that will have MP3 capabilities - with room for 32Mb of
music. Still worried about parser foot-print?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 17 18:47:46 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:09 2004
Subject: UTF-8 vs UTF-16...?
References: <Pine.GSO.4.10.9911171258250.23095-100000@kirk.dnaco.net>
Message-ID: <3832F844.773C122A@pacbell.net>

Kragen Sitaker wrote:
> 
> According to the latest Unicode book (is it version 2.0?  Or 3.0?)
> UTF-8 does not allow you to encode more than the first 17 planes of ISO
> 10646. 

The Unicode book has a bias:  it only talks about the Unicode
aspects of UTF-8.  I've always felt that to be a disservice,
since they didn't develop or standardize UTF-8 and are thus
spreading misinformation.  (They could at least _mention_ the
fact that they're presenting a Unicode subset of full UTF-8!)

Better information is thankfully freely accessible.  See:

    http://www.ietf.org/rfc/rfc2279.txt

which includes the details of the five and six byte encodings.

Note that even with a four byte subset of UTF-8, you can encode
characters that can't be expressed in Unicode.  A few of the
test cases in the OASIS/NIST test suite (these cases happen to
come from James Clark's XMLTEST package) have such characters;
and any conformant XML processor must report a fatal error when
it sees them.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clovett at microsoft.com  Wed Nov 17 19:03:58 1999
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:17:09 2004
Subject: Grafting DOM on a C++ XML parser?
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C155E62E2@RED-MSG-56>

Note: David Brownwell's conformance articles did NOT cover our IE5 COM based
MSXML.DLL.  

-----Original Message-----
From: Ben Berck [mailto:BBerck@ESPS.com]
Sent: Wednesday, November 17, 1999 9:48 AM
To: xml-dev@ic.ac.uk
Subject: Grafting DOM on a C++ XML parser?



Sean of FalconWing wrote: 
>>(Note that there are add-on utilities to graft DOM and SAX2 support to 
>>various popular parsers too) 

We have been burnt with relying on MSXML.DLL, so we have chosen Dundas
Software's new C++ XML parser, which includes source code.  However, I was
disappointed to see that it doesn't support XML DOM.

What add-on utility exists to get the DOM on top of a C++ XML Parser class? 

Thanks, 
Ben Berck 


-----Original Message----- 
From: schen@falconwing.com [ mailto:schen@falconwing.com
<mailto:schen@falconwing.com> ] 
Sent: Wednesday, November 17, 1999 11:42 AM 
To: Sean Mc Grath 
Cc: xml-dev@ic.ac.uk 
Subject: Re: Towards an XML Parser Compliance Table 
Version:17-11-99-15:16 


Hi Sean, everyone, 

David Brownell already wrote up a nice article about this at: 
http://www.xml.com/pub/1999/09/conformance/index.html
<http://www.xml.com/pub/1999/09/conformance/index.html>  
which I can't get to at the moment. 

His test driver can be found at http://home.pacbell.net/david-b/xml/
<http://home.pacbell.net/david-b/xml/>  

>From memory: 

On Wed, 17 Nov 1999, Sean Mc Grath wrote: 

> Fully 1.0 Compliant - Non Validating 
> ------------------------------------- 
4. Sun ProjectX 

> Fully XML 1.0 Compliant - Validating 
> ------------------------------------ 
2. Sun ProjectX 

> Non XML 1.0 Compliant - Non-Validating 
> -------------------------------------- 
aelfred 
DataChannel 
Microsoft 
IBM XML4J 
IBM XML4C 


> Non XML 1.0 Compliant - Validating 
> ---------------------------------- 
> nsgmls (C++) 
> xmlproc (Python) 

IBM XML4J 
IBM XML4C (? I think) 

------------- 
BTW, I think a more useful table would include what other features the 
parsers have, rather than just a strict compliance/validating judgement. 

Example features to consider would be: parser size (why I use aelfred), 
parser speed (why XP is a good choice), language supported (Java/C/C++), 
DOM1 support, DOM2 support, SAX support, SAX2 support, namespace support, 
external entities support, memory usage, maximum file size supported, 
and last but not least character set encodings supported. 

. . . Sean (not related =) 



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991117/75b2806a/attachment.htm
From lauren at sqwest.bc.ca  Wed Nov 17 19:25:34 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:17:09 2004
Subject: Parser compliance
In-Reply-To: <3.0.32.19991117093112.01aad530@pop.intergate.ca>
Message-ID: <199911171922.LAA10266@mail.sqwest.bc.ca>

On 17 Nov 99, at 9:40, Tim Bray wrote:

> I have often wondered where this myth arose that validating against a DTD
> will tell you, in useful real-world terms, "what's wrong with your XML".

Validation doesn't tell you everything that's wrong with your XML, 
but if the DTD (or, in the future, the schema) has been written in a 
useful way (i.e. it isn't too lax), it certainly can tell you *some* 
useful things about what's wrong with your XML. 


Lauren

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



From keshlam at us.ibm.com  Wed Nov 17 20:14:40 1999
From: keshlam at us.ibm.com (keshlam@us.ibm.com)
Date: Mon Jun  7 17:17:10 2004
Subject: Announce: IBM XSL Editor
Message-ID: <8525682C.006F26B3.00@D51MTA03.pok.ibm.com>

For now, your best best for support is the discussion area for this tool on
the alphaWorks website. That doesn't yet appear to be shadowed as a
newsgroup on news.alphaWorks.ibm.com, though I presume it will be soon.

I'll see if I can find the right person to pass your questions to, but
posting them there is likely to yield better answers... and puts the
answers in a place where other users can find them.

______________________________________
Joe Kesselman  / IBM Research



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 20:37:37 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:10 2004
Subject: Announcement of draft-murata-xml-01.txt
In-Reply-To: <199911171131.AA03208@archlute.fujixerox.co.jp>
Message-ID: <000901bf313b$de228920$099918d1@docuverse1>

Murata and Simon,

Thanks for this excellent timely work.

BTW, it would be very nice to see HTML versions of all the
IETF spec with some enhancements like putting emphasis on
key words like 'MUST', 'SHOULD', 'MAY NOT', etc.  It fixes
the hardwired paging problem as well.  Emphasizing of the
keywords might be useful on W3C specs as well since those
keywords can make or break a program's compliance.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at mitretek.org  Wed Nov 17 20:44:24 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:10 2004
Subject: DTD Question - PCDATA followed by an optional element
Message-ID: <001801bf313c$7b0b4c40$38a3f1ce@ls-.mitretek.org>

Here's the correct syntax:

<!DOCTYPE test[
   <!ELEMENT comment (#PCDATA)>
   <!ELEMENT rho0 (#PCDATA| comment)*>
]>

It allows any number of comment elements inside a rho0 element, but it seems to
be the only winning combination.
I just tested this with rxp.

Tom Passin


-----Original Message-----
From: Norman H. Samuelson <nhs@llnl.gov>
To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk>
Date: Wednesday, November 17, 1999 12:04 PM
Subject: DTD Question - PCDATA followed by an optional element


>I have a large number of fields that normally hold simple textual data, but
>might also include a comment.  The XML would look like this with no comment:
>
>   <rho0> 1.0 </rho0>
>
>or this, when the comment is present:
>
>   <rho0> 1.0 <comment> blah, blah </comment> </rho0>
>
>I have no problem in the DTD when I leave out the possibility of a comment,
>I simply use something like this:
>
>   <!ELEMENT rho0 (#PCDATA)>
>
>To include the comment, I would like to be able to simply say:
>
>   <!ELEMENT comment (#PCDATA)>
>   <!ELEMENT rho0 (#PCDATA, comment?)>
>
>That doesn't seem to be acceptable.  I also tried:
>
>   <!ELEMENT rho0 ((#PCDATA) | (#PCDATA, comment))>
>
>Is it possible to do what I want?
>
>If not, I could consider putting one more level of tags around the data,
>like this:
>
>   <rho0> <data> 1.0 </data> <comment> blah, blah </comment> </rho0>
>
>But that adds extra bulk, and code, that should not be needed.  Any
>suggestions would be appreciated.
>
>Whatever solution I come up with must work with IBM's XML4J parser.
>
>
>- Norm -
>
>Norman H. Samuelson                  nhs@llnl.gov
>Lawrence Livermore National Lab      925-422-0661
>P.O. Box 808, L-98
>Livermore, CA 94551
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 20:49:47 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:10 2004
Subject: Feeling good about SML
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E9073@sohos002.ied-support.net>
Message-ID: <001201bf313d$95272580$099918d1@docuverse1>

Mark Birbeck wrote:
>And related to the SML non-debate, I just read that Samsung 
>are bringing
>out a phone that will have MP3 capabilities - with room for 32Mb of
>music. Still worried about parser foot-print?

Still worried I am afraid because it is not just the
size of the parser and applications but how much memory
they need to run.  While I am not expecting the size and
speed differences to exceed 50%, every little bit counts
so it is a matter of benefit/sacrifice ratio.  Note that
I also do not believe this is the primary justification
for SML.

"Simplicity has many rewards, idiocy has many drawbacks.
 -- Don Park

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rgl at decisionsoft.com  Wed Nov 17 21:01:36 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:10 2004
Subject: Parser compliance
In-Reply-To: <3.0.32.19991117093112.01aad530@pop.intergate.ca>
Message-ID: <Pine.LNX.4.10.9911172059500.16362-100000@tugela.dsl.net>

On Wed, 17 Nov 1999, Tim Bray wrote:
> At 12:30 PM 11/17/99 +0000, Richard Lanyon wrote:
> >On Wed, 17 Nov 1999, James Clark wrote:

> >> XML 1.0 DTD validation isn't very useful for the things
> >> I'm interested in and I want to keep the code size small.

> >It's not useful for our processing, either, but it's possible that some
> >people might want our processor to tell them what's wrong with their XML
> >before processing it.

> I have often wondered where this myth arose that validating against a DTD
> will tell you, in useful real-world terms, "what's wrong with your XML".

Not from me, that's for sure. But if people want validation from their XML
processors (and people do, it would seem, possibly because so many XML
books spend so much time talking about validity and DTDs), then we'd
better give it to them or someone else will...

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 21:30:46 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:10 2004
Subject: SML Article/Essay
Message-ID: <001401bf3143$4ea3f100$099918d1@docuverse1>

There is a position paper being written on SML by
Robert La Quey (robertl1@home.com).  The paper will
broaden the scope of discussion to a much wider audience.

If your would like to see your piece of mind reflected
on the paper, please do send him a single paragraph
stating your thought from your own perspective.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 22:39:15 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:10 2004
Subject: Parser compliance
In-Reply-To: Tim Bray's message of "Wed, 17 Nov 1999 09:40:34 -0800"
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca>
Message-ID: <m37ljh6lbs.fsf@localhost.localdomain>

Tim Bray <tbray@textuality.com> writes:

> I have often wondered where this myth arose that validating against
> a DTD will tell you, in useful real-world terms, "what's wrong with
> your XML".

That's probably a rhetorical question, but for those new to the field
(i.e. who didn't come from SGML), SGML consultancies throughout the
1990's made an enormous portion of their money writing (and rewriting
and rerewriting and rererewriting) massive and incomprehensible DTDs
for government, military, and big industry, so naturally they (OK,
"we") hyped the importance of DTDs as the cornerstone of any system.

In XML, I've noticed that most of my consulting work has to do with
designing running systems and integrating components, and that
document-type design is only a small (though important) part of that.

In brief, then, SGML systems tend to be DTD-centric while XML systems
tend to be component-centric.  There's nothing in SGML or XML that
forces that distinction; it's just the way things fell out.  Tim's
right -- DTD-based validation will tell you only a tiny portion of
what's wrong with your document, though that portion can be helpful
in some circumstances.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 22:34:49 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:10 2004
Subject: (My) Feeling About SML
In-Reply-To: <007d01bf310a$3f266ca0$f9d18dce@WORKGROUP>
Message-ID: <001801bf314c$3b3d1e80$099918d1@docuverse1>

Thanks to Leigh and Michael for this excellent subthread,

I do agree that there is a problem with API complexity.
DOM is a nice API but rather big and complex for certain
applications and results in rather verbose code.  Having
a 'limited subset' spec/guide would certainly help in
defining a simpler DOM (SDOM if you will).

SAX is simple but it is difficult to use in applications
where access to yet-to-come elements and character data is
needed.  Getting around this problem complicates the XML
application.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 22:39:20 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:10 2004
Subject: Parser compliance
In-Reply-To: Richard Lanyon's message of "Wed, 17 Nov 1999 09:41:13 +0000 (GMT)"
References: <Pine.LNX.4.10.9911170932510.13216-100000@localhost.localdomain>
Message-ID: <m3g0y56mhl.fsf@localhost.localdomain>

Richard Lanyon <rgl@decisionsoft.com> writes:

> Anyway, the point is that the issue of different XML document
> layouts for different parsers is not merely one of conformance, but
> of the number of optional features as well (something particularly
> telling in the light of the cut-down XML debate currently continuing
> on this list).

Yes, I agree -- in retrospect, it was a technical mistake to allow so
many optional features in XML, though that mistake is really just an
annoyance to us techies and hasn't inhibited the spread of XML in the
wider world, at least not yet.

Off the cuff, I can think of the following major optional features in
the XML 1.0 REC:

1. Validation
2. Inclusion of external general entities (if non-validating)
3. Inclusion of external parameter entities (if non-validating)

Since many major specs now rely on Namespaces, you can add

4. Namespace processing

(even though that's not part of XML 1.0).  Furthermore, validation
needs to be broken down quite a bit: for example, a non-validating
processor may still read element type declarations and distinguish
whitespace in element content (as AElfred does) and may still perform
ID/IDREF verification.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 22:39:19 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:10 2004
Subject: Parser compliance
In-Reply-To: Sebastian Rahtz's message of "Wed, 17 Nov 1999 14:54:01 +0000 (GMT)"
References: <Sean Mc Grath's message of "Tue, 16 Nov 1999 17:36:19 +0000"> <3.0.6.32.19991116173619.0092d320@gpo.iol.ie> <3.0.6.32.19991117140109.0092f8c0@gpo.iol.ie> <14386.49545.809454.247811@spqr.oucs.ox.ac.uk>
Message-ID: <m3d7t96mev.fsf@localhost.localdomain>

Sebastian Rahtz <sebastian.rahtz@computing-services.oxford.ac.uk> writes:

> Sean Mc Grath writes:

>  > Fully 1.0 Compliant - Non Validating
> ...
>  > 2. XT
>  > 
> XT is not an XML parser. It uses XP. 

My fault -- I initiated the typo, and Sean simply disseminated it.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 22:39:18 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:10 2004
Subject: Do SGML and XML co-exist?
In-Reply-To: Len Bullard's message of "Tue, 16 Nov 1999 22:49:28 -0600"
References: <383233D8.46BC@hiwaay.net>
Message-ID: <m3aeod6lug.fsf@localhost.localdomain>

Len Bullard <cbullard@hiwaay.net> writes:

> David Megginson:
> 
> >This is a good thing -- it would have been fine if XML had died and
> >full SGML had won, and it's fine the way it is, but if both SGML and
> >XML had been equally strong competitors, we would have been dealing at
> >best with the same problem people have with OpenGL/DirectX,
> >CORBA/RMI/DCOM, etc.
> 
> Interesting, but nah.  XML won because Microsoft backed 
> it.  Plain and simple.

Nah.  I know that Len is too savvy to believe that, really -- after
all, Microsoft has backed so many losing specs over the past few years
(and then quietly backed away, leaving naive smaller partners
dangling) that the effect of their backing alone cannot have helped
XML get to where it is.

What's special about XML is that *both* Microsoft *and* the
anyone-but-Microsoft camp (Sun, IBM, Oracle, and Netscape [at the
time]) backed it.  That's extremely rare (usually you have to choose
between OpenGL or DirectX, CORBA or DCOM, Java or ActiveX, NFS or SMB,
etc. etc.) -- heartfelt kudos to Jon, Tim, and the other members of
the original XML WG for getting XML safely through that minefield.

> The differences between the features of the practice aren't that
> great.  The size is.  The money came and when the money voted, the
> money voted for a namechange and a change of venue.  Selah.  Same
> dumb stuff, just cheaper and better integrated into the windowing
> system and the network.

Yep, that's about it, but brain-dead simplicity is a good survival
characteristic in the early stages (when most specs die) because the
barrier to entry is lower -- hence the successes of HTML and XML.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 22:53:03 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun  7 17:17:10 2004
Subject: XML/XSL position avaliable
References: <001201bf313d$95272580$099918d1@docuverse1>
Message-ID: <38332FAF.633338EE@cs.ucsd.edu>


Internet startup with Stanford/UCSD founders looks for exceptionally
good Web designer with experience in XML and XSL.
We offer exceptionally good salary and equity options.
This is a great chance to join a pioneering ecommerce company in
its beginnings. Company is CA based.

Please contact yannis@cs.ucsd.edu

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 17 23:00:36 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:10 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
In-Reply-To: "Don Park"'s message of "Wed, 17 Nov 1999 12:51:49 -0800"
References: <001201bf313d$95272580$099918d1@docuverse1>
Message-ID: <m31z9o7mp2.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> Still worried I am afraid because it is not just the
> size of the parser and applications but how much memory
> they need to run.  While I am not expecting the size and
> speed differences to exceed 50%

Here are the significant dynamic memory requirements for a conformant,
non-validating XML 1.0 processor that uses an event-based interface:

a) a dynamic buffer for reading names -- its maximum length will be
   the length of the longest name (element name, attribute name, or PI
   target) in the document;

b) a buffer for reading a chunk of data or an attribute value (with
   SAX, its maximum length will be the length of the longest attribute
   value in the document);

c) a stack of the names of currently-open elements so that you can
   match start/end tags; its maximum size will be the depth of
   element nesting in the document (usually under 20 in my
   experience);

d) a map of declared default attribute values;

e) an array of attribute names seen while each start tag is being
   processed (it can be freed as soon as the start-element event has
   been reported); its maximum size will be the greatest number of
   attributes (defaulted and specified) for a single element (usually
   under 10 in my experience, maybe 20 with TEI);

f) a whole bunch of big tables or sets of start/end values for
   checking which Unicode characters are allowed in which contexts;
   and

g) a stack or state variable keeping track of what's currently being
   parsed (i.e. "in comment" or "looking for name").

Note that supporting PIs and comments doesn't really add anything to
the memory requirements, since you can use the same buffers that you
use to read names and character data.

If SML eliminated attributes altogether, you could make (b) a little
shorter (say, 512 characters max), though few documents have attribute
values longer than 512 characters and you could eliminate (d), which
might save 2K or so, and (e) which might save another 1K or so for a
document that really beats up on attributes, but you'd have to add a
bit to (c) for the new elements required to replace the attributes --
let's say, then a 3K saving in memory consumption for processing a
large document if attributes are forbidden.

>, every little bit counts
> so it is a matter of benefit/sacrifice ratio.  Note that
> I also do not believe this is the primary justification
> for SML.

Good, because unless I've missed something obvious, a 3KB memory
saving probably lands on the wrong side of that ratio.

Again, the big problem in creating a tiny XML processor is the
required error reporting for illegal characters in names, attribute
values, etc. -- if you build lookup tables, you're looking at an
enormous amount of memory for each table.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kragen at pobox.com  Wed Nov 17 23:16:32 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:17:10 2004
Subject: DTD Question - PCDATA followed by an optional element
Message-ID: <Pine.GSO.4.10.9911171813260.4948-100000@kirk.dnaco.net>

Norman Samuelson asks:
>To include the comment, I would like to be able to simply say:
>
>   <!ELEMENT comment (#PCDATA)>
>   <!ELEMENT rho0 (#PCDATA, comment?)>
>
>That doesn't seem to be acceptable.  I also tried:
>
>   <!ELEMENT rho0 ((#PCDATA) | (#PCDATA, comment))>
>
>Is it possible to do what I want?

No.  Section 3.2.2 of REC-xml:
	An element type has mixed content when elements of that type
	may contain character data, optionally interspersed with child
	elements. In this case, the types of the child elements may be
	constrained, but not their order or their number of
	occurrences:

The best you can do is (#PCDATA|comment)*.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 00:08:56 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun  7 17:17:11 2004
Subject: Parser compliance
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain>
Message-ID: <383343AA.EBB9B115@allette.com.au>


David Megginson wrote:

> That's probably a rhetorical question, but for those new to the field
> (i.e. who didn't come from SGML), SGML consultancies throughout the
> 1990's made an enormous portion of their money writing (and rewriting
> and rerewriting and rererewriting) massive and incomprehensible DTDs
> for government, military, and big industry, so naturally they (OK,
> "we") hyped the importance of DTDs as the cornerstone of any system.

Are you suggesting that we would have done the client a favour by disregarding structure and
steering them toward a good word processor? It's a bit disingenuous to criticise what was far
and away the best solution at the time. It was no more or less a money-grab than the current
market.

> In brief, then, SGML systems tend to be DTD-centric while XML systems
> tend to be component-centric.  There's nothing in SGML or XML that
> forces that distinction; it's just the way things fell out.

Surely you're not suggesting that structure is less important if you have semantically correct
data? The two go hand in hand, revealing different yet related aspects of the document. I
don't see the distinction.

> Tim's
> right -- DTD-based validation will tell you only a tiny portion of
> what's wrong with your document, though that portion can be helpful
> in some circumstances.

That has always been the case - it's never been enough just to make the document valid. Not in
SGML and not in XML. The diminished requirement for a DTD in XML doesn't diminish the need for
structure - we're just assuming that control might rest with some other mechanism. The fact
that we're getting more control over the data contents of elements is fantastic, as it has
always been required, but it doesn't change the fact that something has to understand the
structure too. I think that this thread is turning into a simple rewrite of history.


--
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 00:24:23 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:11 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
Message-ID: <3.0.32.19991117162449.01abfa10@pop.intergate.ca>

At 05:55 PM 11/17/99 -0500, David Megginson wrote:
>Again, the big problem in creating a tiny XML processor is the
>required error reporting for illegal characters in names, attribute
>values, etc. -- if you build lookup tables, you're looking at an
>enormous amount of memory for each table.

Actually, it's not so bad as all that.   The trick is this: there are 
only a few interesting states, of which you're in one of these 3 most of
the time:

 - processing character data
 - processing a name (e.g. element type or attribute name)
 - processing the first character of a name

For the first, can check the small number of excluded regions with
an if statement.

For the others, you have a (relatively) small array of pairs of 
numbers being the low-high edges of legal ranges, then you binary-search
them.  In Lark, the class that does all the work is only 3.5K (the
arrays are compressed in the class file, so maybe 10* times in memory).

The performance is good enough that in Lark, the limiting factor was
my lousy input buffering, not the character class checking; and Lark
was always in the top half of the performance table. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Thu Nov 18 00:26:50 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:11 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
References: <001201bf313d$95272580$099918d1@docuverse1> <m31z9o7mp2.fsf@localhost.localdomain>
Message-ID: <01e601bf315b$6d6a9630$f9d18dce@WORKGROUP>


----- Original Message -----
From: David Megginson <david@megginson.com>
To: <xml-dev@ic.ac.uk>
Sent: Wednesday, November 17, 1999 5:55 PM
Subject: XML Memory Requirements (was Re: Feeling good about SML)


Thanks for such an informative posting!

> Again, the big problem in creating a tiny XML processor is the
> required error reporting for illegal characters in names, attribute
> values, etc. -- if you build lookup tables, you're looking at an
> enormous amount of memory for each table.

Could you elaborate a bit here for the benefit of those of us who are not
familiar with the finer points of the XML spec with respect to "illegal
characters in names, attribute values, etc."

More procedurally, let's say for the sake of argument that one were
designing an XML-like metalanguage with the goal of making its processors as
small and fast as possible. Are there plausible ways of loosening XML's
"required error reporting" to make it easier to write parsers without big
lookup tables?

Again, this is the voice of inexperience speaking so be merciful if I'm
missing something obvious ... but in an "SML" without entities, attributes,
PIs, and comments, and without any concern for maintaining SGML
compatibility,  I can't think of too many printable characters besides "<"
">" and maybe " " that *have* to be illegal in element names. I can think of
a lot of characters that sensible people probably would not put in their
markup, but that's another matter, and arguably not the job of the SML
parser to enforce.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 00:45:14 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:11 2004
Subject: Grafting DOM on a C++ XML parser?
References: <2F2DC5CE035DD1118C8E00805FFE354C155E62E2@RED-MSG-56>
Message-ID: <38334C13.BD96E5F7@pacbell.net>

Chris Lovett wrote:

> Note: David Brownell's conformance articles did NOT cover
> our IE5 COM based MSXML.DLL.  

"yet" ... ;-)




[
  By the way -- is it just me, or are other folk getting
  both duplicate messages and substantially delayed ones
  from the xml-dev list??  For example, the message to
  which Chris' note responded hasn't shown up here yet,
  neither has a note from Tim Bray that I've seen, nor
  one I posted this morning.
]

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 00:50:33 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:11 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
References: <3.0.32.19991117092816.0152e5f0@pop.intergate.ca>
Message-ID: <00b501bf315e$dabf7310$eb020a0a@bowstreet.com>

> At 06:04 AM 11/17/99 -0500, James Tauber wrote:
> >UTF-16, however, only gives access to the equivalent of Unicode with the
> >surrogate extension mechanism, ie the first 17 planes of the UCS.
>
> Right, a mere million extra characters in excess of what we're using now.
>
> This feels like a pretty low-risk option to me.

Oh, I agree. I wrote to Steinar privately saying that there is no
*practical* difference in coverage. I was just being picky.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 18 01:36:26 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:11 2004
Subject: Parser compliance
In-Reply-To: <m37ljh6lbs.fsf@localhost.localdomain>
Message-ID: <000401bf3165$9aaf4960$099918d1@docuverse1>

David Megginson wrote:

>In XML, I've noticed that most of my consulting work has to do with
>designing running systems and integrating components, and that
>document-type design is only a small (though important) part of that.

Aye.  When prospective clients ask me to write their DTD, I tell them
that the design of XML-based systems require looking at the big picture
of component integration and data flow.  DTD is just 'what' but there
are 'how', 'where', 'when', etc. to consider.  Often times, DTD is just
used for documentation.

Too bad that my comments often taken as an attempt to increase the size
of the bill.  Not that I am entirely innocent, of course. <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Thu Nov 18 01:39:41 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:17:11 2004
Subject: Grafting DOM on a C++ XML parser?
References: <2F2DC5CE035DD1118C8E00805FFE354C155E62E2@RED-MSG-56> <38334C13.BD96E5F7@pacbell.net>
Message-ID: <002f01bf3166$4c7c4120$20fbb1cd@tomshp>

You're not the only one, David.

Tom Passin

----- Original Message ----- 
From: David Brownell <david-b@pacbell.net>
<snip>
> [
>   By the way -- is it just me, or are other folk getting
>   both duplicate messages and substantially delayed ones
>   from the xml-dev list??  For example, the message to
>   which Chris' note responded hasn't shown up here yet,
>   neither has a note from Tim Bray that I've seen, nor
>   one I posted this morning.
> ]
</snip>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 01:37:11 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:11 2004
Subject: Parser compliance
In-Reply-To: <3.0.32.19991117093112.01aad530@pop.intergate.ca> (message from
	Tim Bray on Wed, 17 Nov 1999 09:40:34 -0800)
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca>
Message-ID: <199911180130.TAA00892@bruno.techno.com>

[Tim Bray:]
> I have often wondered where this myth arose that validating against
> a DTD will tell you, in useful real-world terms, "what's wrong with
> your XML".

I have often wondered where this myth arose that DTDs are somewhere
between evil and useless.  It's baffling that this myth arises when
there's nothing better than, or even as good as DTDs.  Meanwhile,
perhaps because of this myth, several serious W3C efforts appear to be
taking giant steps backward from providing even the usefulness that
DTDs do in fact provide.  I have no adequate explanation for this.
I'm putting it down to some new electronic form of mass engineering
hysteria, in which rumors, perhaps based on casual and unguarded
remarks of experts, shape public opinion in unintended ways that work
against the public interest.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 01:36:51 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:11 2004
Subject: Do SGML and XML co-exist?
In-Reply-To: <383233D8.46BC@hiwaay.net> (message from Len Bullard on Tue, 16
	Nov 1999 22:49:28 -0600)
References: <383233D8.46BC@hiwaay.net>
Message-ID: <199911180113.TAA00876@bruno.techno.com>

[Len Bullard:]
> Reading the specs, they link off into some mysterious InfoSet black
> hole that stops at the event horizon of a login.  Kind of reminds me
> of ... Hytime.  MMTT.

Yeah, except that HyTime is more general, simpler, and easier to build
applications on.  It uses less machinery to do more, and without
imposing unnecessary constraints.  Also:

* HyTime doesn't confound interchange structure with the properties of
  the interchanged information,

* HyTime is syntax-agnostic, and 

* HyTime really delivers on the promise of re-usable software for
  vocabularies, even when vocabularies are mixed together and/or
  inherit each other.

Come to think of it, more and more people are finding themselves in a
position to appreciate HyTime these days.  

<confidential>HyTime is XML compatible.</confidential>

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:00:58 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:11 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
In-Reply-To: "Michael Champion"'s message of "Wed, 17 Nov 1999 19:25:32 -0500"
References: <001201bf313d$95272580$099918d1@docuverse1> <m31z9o7mp2.fsf@localhost.localdomain> <01e601bf315b$6d6a9630$f9d18dce@WORKGROUP>
Message-ID: <m3vh705zs5.fsf@localhost.localdomain>

"Michael Champion" <Mike.Champion@softwareag-usa.com> writes:

> Again, this is the voice of inexperience speaking so be merciful if I'm
> missing something obvious ... but in an "SML" without entities, attributes,
> PIs, and comments, and without any concern for maintaining SGML
> compatibility,  I can't think of too many printable characters besides "<"
> ">" and maybe " " that *have* to be illegal in element names. I can think of
> a lot of characters that sensible people probably would not put in their
> markup, but that's another matter, and arguably not the job of the SML
> parser to enforce.

I think that this is a lot more on the money than most of the SML
discussion -- if we want to be able to build really, really small XML
processors, we're going to have to lighten the error-reporting
requirements quite a bit, somehow.

Actually, it's not that expensive to be picky about characters 0x00 to
0xff, since the tables will be small; above 0xff, things become
trickier if you're trying to keep your parser's total footprint small
enough for embedded systems (say, <20K including both code, stack, and
dynamic memory, which is otherwise quite doable with XML 1.0).  Unless
embedded systems get a lot bigger, the error-reporting requirement is
going to be the real hurdle to implementation.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:18:43 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:11 2004
Subject: Do SGML and XML co-exist?
References: <383233D8.46BC@hiwaay.net> <383282B1.D82B1D0F@praxis.cz>
Message-ID: <383359D1.6948@hiwaay.net>

Matthew Gertner wrote:
> 
> Yeah? I always tell the same story about the origins of XML, so I'd be
> interested to know if it is wrong. :-O Basically, goes the story, round
> about the genesis of HTML 4.0 the HTML folks started to realize that
> even with the best of intentions and a heck of a lot of hard work they
> were never going to get even a small proportion of the tags that people
> (and influential companies) wanted into the language.

Somewhere in the oldenMailFiles, I have the request from an influential 
HTMLer to help "get it on track, they are on a suicide march".  I read 
what the WG was doing and told Behlendorf that until they actually began 
to understand the limits of markup systems, it was hopeless, so he 
should start understanding SGML and drop the WebIsHoly religion.  Later, 
I got the sad occasion to explain to a Netscape product manager for 
the browser that Andreesen's bold statements in France about the 
"propritariness of XML" were the rantings of a dieing exec.  They 
waited for six months and by then, they were dead on the vine.  

Predictable, avoidable, and completely their own fault.  Pennfield 
can rule stupidly, but MS's competitors killed themselves 
with their own ignorance and pride and press.

> Moreover, the
> undesirability of this approach, even if practicable, was starting to
> become clear (witness the length of the HTML 4.0 spec).

Every markup specialist in the world knew as soon as HTML was released 
what it was, where it would work, and what the flaws were.  Everyone 
tries GenCode at least once.   In the original form, according to 
Yuri, it was end-tagged (a la RTF) and some folks had to work with 
the inventor to make it a markup application.
 
> So they started to dream up something along the lines of generic markup
> using ghastly DIV and CLASS tags. This came to the notice of the SGML
> folks, who screamed bloody murder and started lobbying for SGML, with
> its time-tested approach to generic markup, to be the new language for
> the web. 

No.  It started earlier than that.  SGML hypertext systems with
stylesheets 
were already on the market prior to 1990.  Some systems had been being 
worked since ISO8879 was a draft.  Long before XML, the SGML community 
had debated it on comp-text-sgml.  The problem was not complexity but 
the inanity of the HTML working group.  Hytime and DSSSL, yes, these 
are complex, but to be blunt, put all of the XML specs together, 
throw them on the floor, and see how loud a thump they make.

Beware facile demonstrations of simplicity.  Bosak knows it was 
a show piece and that once the work was underway, it would 
fatten out.  It didn't matter.

> The reaction of the HTML crowd was immediate: not SGML, of all
> things, it's far too scary and complicated! So some forward-thinking
> types from the SGML community came up with the idea of simplying SGML
> significantly in order to make it acceptable as a mass-market web
> language. Whence XML.

People had been simplifying the application of SGML all along.  I had 
discussions with Charles Goldfarb about that at the very first HyTime 
meeting I attended. His answers were along the line that as long as 
the system was a proper subset, it did not violate SGML.  He thought 
it strange anyone insisted on implementing all of the features of SGML 
given that some were there for particular purposes.  It was Charles 
and Yuri Rubinsky that took IADS to a NIST meeting to prove that SGML 
could indeed be used for simple, cheap, and easy to apply hypertext. 
The reasons we were writing conformance tests for the US Navy was 
that none existed so no one knew how to buy an SGML system.  If you 
asked SoftQuad or ArborText or Datalogics, the multiplicity of 
answers was staggering.  Hungry, desperate competitors make 
bad advisors for conformance, The SGML Way, it was called, and with 
that, competitors eliminated simple solutions in favor of a spectre 
they couldn't themselves enunciate in concordance.   Once the money 
was there, it didn't matter.

XML was SGML On The Web when the idea was introduced at the Vancouver 
meetings.  Some of us had heard the rumblings and were ready to 
support it.  I for one was not prepared for the coup d'etat that 
followed but I could see it coming after an argument with Jean 
Paoli in the hallway about how to go about it.  He kept insisting 
"it must be simple, it must be easy" and I replied, "no one 
disagrees, but it must be SGML."  At that moment, I realized 
what was coming and that the SGMLers whose hopes that Microsoft 
sponsorship was a new hope would get what the wanted.  Yuri had 
told me a year or so earlier, "Yes Len, I know HTML is hopeless, 
but for the first time, SoftQuad is actually making money."  
 
> Am I close? Assuming so, technical issues certainly were the primary
> motivating factor for XML. 

Not really.  It was something doable technically and we had the 
existence proofs.  After that, it was a political exercise in 
divesting ISO of authority and conferring it on the W3C.  There 
are some stories you don't hear, Matthew, and some of them are 
involve some very old and bitter rivalries for control.  Those 
had weakened the community considerably.  The CALS days were 
fairly flush, but even then, the WYSIWYG Wars had weakened 
the Republic, so the advent of the Empire was easy to fortell. 

> Denying this is a pretty extreme view (not
> that this surprises me, Len :-). The "features of the practice" may not
> be all that different, but the fact that to write a conformant SGML
> parser you needed (according to one statement I heard at an SGML
> conference as XML was coming to the fore) "to have the resources of the
> U.S. government or to be James Clark"

Point was, we already had a conformant parser.  The issues revolved 
around the anemia of using the web transport mechanisms and stateless 
protocols.  SGML requires the use of the DTD to do some magick. 
Sensible designers knew that wasn't necessary.

> surely had something to do with
> the chorus of demands for simplication in exchange for ubiquity. Not
> everything is a money-driven conspiracy.

Not everything is.  IADS was designed and coded by a political 
science major and a photographer.  You see, sometimes, it doesn't 
pay to be a computer scientist contending with the More Meta Than 
Thou crowd.  Essentially, even when you have a full toolkit, 
you may only need a screwdriver.  

It doesn't matter now, but since defending XML against the 
ravages of possible upstarts such as SML sounds a lot 
like Stalin defending against Trotsky, it helps to have 
a few dialogues for historians to mulch later.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:20:08 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:11 2004
Subject: Do SGML and XML co-exist?
References: <383233D8.46BC@hiwaay.net> <m3aeod6lug.fsf@localhost.localdomain>
Message-ID: <38335F04.1303@hiwaay.net>

David Megginson wrote:
> 
> Nah.  I know that Len is too savvy to believe that, really -- after
> all, Microsoft has backed so many losing specs over the past few years
> (and then quietly backed away, leaving naive smaller partners
> dangling) that the effect of their backing alone cannot have helped
> XML get to where it is.

That was the danger expressed to Murray in Vancouver, but it looks 
like the survivors figured it out.  Yes, MS or any company including 
the Feds can leave one hanging.  But this is so:  if Jean Paoli 
had NOT come to Vancouver, and certain parties not persuaded the 
IE product managers that SGML was the key to getting six month 
lead on the then dominant browser, that this innovation would 
work where every other form of arm twisting would fail, we 
would be debating this on comp-text-sgml.

> What's special about XML is that *both* Microsoft *and* the
> anyone-but-Microsoft camp (Sun, IBM, Oracle, and Netscape [at the
> time]) backed it.  

No they didn't.  Andreesen went on record in Paris with extremely 
strong and extremely wrong statements about XML.  I sat with 
the Netscape product manager and had a long discussion in 
Monterey.  Netscape was late to the party.  Sun found something for Java 
to do and Oracle joined the party once the W3C pushed hard.  No, 
in the beginning, David, it was just us chickens and Little Blue. 
MS was the smartest bunch in the pack.  Do they do unscrupulous 
things?  I don't know, but when it comes to recognizing an 
opportunity and working it, no one is better.  Give 'em credit 
for knowing how to work the room.

>  That's extremely rare (usually you have to choose
> between OpenGL or DirectX, CORBA or DCOM, Java or ActiveX, NFS or SMB,
> etc. etc.) -- heartfelt kudos to Jon, Tim, and the other members of
> the original XML WG for getting XML safely through that minefield.

Yep.  That part is true. Jon and Tim did a good job of getting XML 
framed and named.  It is what it is and that is the way it goes. 

> > The differences between the features of the practice aren't that
> > great.  The size is.  The money came and when the money voted, the
> > money voted for a namechange and a change of venue.  Selah.  Same
> > dumb stuff, just cheaper and better integrated into the windowing
> > system and the network.
> 
> Yep, that's about it, but brain-dead simplicity is a good survival
> characteristic in the early stages (when most specs die) because the
> barrier to entry is lower -- hence the successes of HTML and XML.

Yep.  All that free stuff in IE5 doesn't hurt either.  Getting my 
manager to recognize that using the DOM class was a better bet 
on import was a bit of work, but once he worked with it, things 
picked up.

Hard for some to believe here, but getting hardcore FoxPro and 
Oracle hackers to use XML is still a struggle.

Now, that thing about schemas....  

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:23:46 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:11 2004
Subject: Parser compliance
In-Reply-To: Marcus Carr's message of "Thu, 18 Nov 1999 11:09:15 +1100"
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain> <383343AA.EBB9B115@allette.com.au>
Message-ID: <m3so245ypz.fsf@localhost.localdomain>

Marcus Carr <mrc@allette.com.au> writes:

> Are you suggesting that we would have done the client a favour by
> disregarding structure and steering them toward a good word
> processor? 

The DTD has two small but important roles in system implementation: as
a partial set of structural validation rules and as a partial schema
for guided authoring (it's nearly always supplemented in both cases).

Unfortunately, SGML consultancies who knew mainly just DTDS and FOSIs
were substituting DTD design for data analysis, domain modelling,
system design, user interface design, and lots of other things for
which DTDs are woefully inadequate.

> It's a bit disingenuous to criticise what was far and away the best
> solution at the time. It was no more or less a money-grab than the
> current market.

DTDs should have been just part of the solution, not *the* solution.
There's nothing special about this -- consultants do the same thing in
other areas as well.  I'm sure many of us have seen a consulting
company spend the entire allotted time for a project (and more)
drawing enormously complicated UML diagrams, and then hand the
diagrams to the customer say "OK, here's your system, now you can
implement it."

In any case, my message was an explanation of why DTDs have been so
heavily hyped, not an attack on the idea of DTDs themselves.  DTDs
were the great Golden Hammer of the SGML consulting world.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:25:09 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:11 2004
Subject: Towards an XML Parser Compliance Table Version:17-11-99-15:16
References: <Pine.LNX.3.96.991117113240.5565A-100000@www.falconwing.com>
Message-ID: <3833637A.A2CAF7F4@pacbell.net>


> BTW, I think a more useful table would include what other features the
> parsers have, rather than just a strict compliance/validating judgement.
> 
> Example features to consider would be: parser size (why I use aelfred),
> parser speed (why XP is a good choice), language supported (Java/C/C++),
> DOM1 support, DOM2 support, SAX support, SAX2 support, namespace support,
> external entities support, memory usage, maximum file size supported,
> and last but not least character set encodings supported.

Size, speed, and memory are unrelated to spec conformance; seems to
me they should be in a different table.


A curious attribute to consider:  what's the length of the longest
name (or name token) the parser can accept?

Straightforward implementations of an XML parser will often end up
putting some sort of limit there, for example 4K characters might
be an internal buffer size.  With a bit of work, such limitations
can sometimes be removed.

While I would assert that anyone using 4K character names is really
asking for trouble (even in computer generated output!), I'd expect
that an embedded XML engine might find good reasons to have much lower
limits, such as 16 or 32 characters.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:25:51 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:11 2004
Subject: Do SGML and XML co-exist?
References: <383233D8.46BC@hiwaay.net> <199911180113.TAA00876@bruno.techno.com>
Message-ID: <3833622A.7EA7@hiwaay.net>

Steven R. Newcomb wrote:
> 
> Come to think of it, more and more people are finding themselves in a
> position to appreciate HyTime these days.

I noted the post from someone that said, "it may turn out 
that the Hytime guys were right all along".  I think 
the issues of emergence have more to do with processor 
power... and that thing about specs Mikey likes and Mikey 
can understand.

> <confidential>HyTime is XML compatible.</confidential>

Dang!  Now I have no excuse.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:25:55 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:11 2004
Subject: Parser compliance
References: <000401bf3165$9aaf4960$099918d1@docuverse1>
Message-ID: <383362B5.F34@hiwaay.net>

Don Park wrote:
 
> Aye.  When prospective clients ask me to write their DTD, I tell them
> that the design of XML-based systems require looking at the big picture
> of component integration and data flow.  DTD is just 'what' but there
> are 'how', 'where', 'when', etc. to consider.  Often times, DTD is just
> used for documentation.

Perhaps learning how to use a DTD, where to use a DTD, and when to use 
a DTD, and let me add, when to modify it, are just as important as 
what a DTD is.  Your clients may have something besides money; 
common sense.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 18 02:27:34 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:12 2004
Subject: DTD Question - PCDATA followed by an optional element
Message-ID: <004d01bf316f$ed17e400$33f96d8c@NT.JELLIFFE.COM.AU>


From: Richard Tobin <richard@cogsci.ed.ac.uk>

>> I have a large number of fields that normally hold simple textual
data, but
>> might also include a comment.
>
>You can't constrain the content in that way with a DTD.  The best you
>do is
>
>    <!ELEMENT rho0 (#PCDATA|comment)*>
>
>which allows any mixture of comments and text.

To get strong typing you either must

1)explicitly label the text section:
    <!ELEMENT rho0 (text, comment?)>
    <!ELEMENT text (#PCDATA)>

or
2) use some other schema language to validate: use a DTD with Richard's
    <!ELEMENT rho0 (#PCDATA|comment)*>

Then the following Schematron schema to check that only one comment is
used (I think this is correct, I haven't run it):
<schema><title>Norman's Schema</title>
    <pattern name="Rho0 Pattern">
        <rule context="rho0">
            <assert text="count(comment) &lt;= 1"
            >An rh0 element should have only one comment</assert>
        </rule>
    </pattern>
</schema>

You can download schematron-report, which is an error browser generating
HTML pages, from
http://www.ascc.net/xml/resource/schematron/schematron.html

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:36:58 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:12 2004
Subject: Do SGML and XML co-exist?
In-Reply-To: <38335F04.1303@hiwaay.net>
References: <383233D8.46BC@hiwaay.net>
	<m3aeod6lug.fsf@localhost.localdomain>
	<38335F04.1303@hiwaay.net>
Message-ID: <14387.25867.236209.756491@localhost.localdomain>

Len Bullard writes:

 > I sat with the Netscape product manager and had a long discussion
 > in Monterey.  Netscape was late to the party.  Sun found something
 > for Java to do and Oracle joined the party once the W3C pushed
 > hard.  No, in the beginning, David, it was just us chickens and
 > Little Blue.  MS was the smartest bunch in the pack.  Do they do
 > unscrupulous things?  I don't know, but when it comes to
 > recognizing an opportunity and working it, no one is better.  Give
 > 'em credit for knowing how to work the room.

Yes, and admittedly Len knows much more about the early history than I
do, since I wasn't in on those meetings.

I think that we're making different points, though -- my point is that
in the crucial few months immediately *after* XML 1.0 went to REC,
when it had a flash of media attention and had to either gain quick
acceptance or join the very large scrapheap of politely-ignored specs,
XML had or acquired the backing of Sun, IBM, Oracle, and even Netscape
as well as MS.  If XML had gone to REC with only MS and its hangers-on
backing it, it would probably have failed or at least spluttered a
lot.

To Microsoft's credit, they were in the game early (I know that it
took a long time for Sun to really notice XML, even though Jon was
chairing the committee), but that doesn't matter as much to the
outside world, as long as everyone's there at the end.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 02:56:49 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:12 2004
Subject: Parameter Entity Replacement and the XML 1.0 Grammar
References: <4.2.0.58.19991117100310.00bf82c0@pop1.attglobal.net>
Message-ID: <38336AE5.B65E4366@pacbell.net>

"G. Ken Holman" wrote:
> 
> Today I started using a validating parser on the source file and it is
> choking on the entity declaration.

...

> My belief is I've been working properly all along, XT is correct, and the
> new parser is incorrect.

I'd think so too -- though XT isn't a parser, so it'd be some parser
that you'd previously have configured XT to use, perhaps XP.


> <!ENTITY % e "wmf"><!--non .gif extension-->
> <!NOTATION %e; SYSTEM "">
	... 4.4.8 expands to <!NOTATION wmf SYSTEM "">
> <!ENTITY % filename "'abc.%e;'">
	... 4.4.5 expands to <!ENTITY % filename "'abc.wmf'">
> <!ENTITY abc SYSTEM %filename; NDATA %e;>
                      ^ diagnostic points here
	... 4.4.8 expands to <!ENTITY abc SYSTEM 'abc.wmf' NDATA wmf>

> [Fatal Error] test.ent:4:21: The system identifier must begin with either a
> single or double quote character.

That looks fine to me.  Looks like the new parser is stripping out the
single quotes, so %filename; expands incorrectly.  I'd try a different
validating parser -- specifically Sun's, which does well on the OASIS
tests.  (It's the only validating Java parser which does at this time,
so far as I know.)

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clovett at microsoft.com  Thu Nov 18 03:08:21 1999
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:17:12 2004
Subject: Grafting DOM on a C++ XML parser?
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C155E6310@RED-MSG-56>

Hopefully this is now cleared up with David's latest article
http://www.xml.com/pub/1999/11/parser/index.html
<http://www.xml.com/pub/1999/11/parser/index.html> 

-----Original Message-----
From: Chris Lovett [mailto:clovett@microsoft.com]
Sent: Wednesday, November 17, 1999 11:03 AM
To: 'Ben Berck'; xml-dev@ic.ac.uk
Subject: RE: Grafting DOM on a C++ XML parser?


Note: David Brownwell's conformance articles did NOT cover our IE5 COM based
MSXML.DLL.  

-----Original Message-----
From: Ben Berck [mailto:BBerck@ESPS.com]
Sent: Wednesday, November 17, 1999 9:48 AM
To: xml-dev@ic.ac.uk
Subject: Grafting DOM on a C++ XML parser?



Sean of FalconWing wrote: 
>>(Note that there are add-on utilities to graft DOM and SAX2 support to 
>>various popular parsers too) 

We have been burnt with relying on MSXML.DLL, so we have chosen Dundas
Software's new C++ XML parser, which includes source code.  However, I was
disappointed to see that it doesn't support XML DOM.

What add-on utility exists to get the DOM on top of a C++ XML Parser class? 

Thanks, 
Ben Berck 


-----Original Message----- 
From: schen@falconwing.com [ mailto:schen@falconwing.com
<mailto:schen@falconwing.com> ] 
Sent: Wednesday, November 17, 1999 11:42 AM 
To: Sean Mc Grath 
Cc: xml-dev@ic.ac.uk 
Subject: Re: Towards an XML Parser Compliance Table 
Version:17-11-99-15:16 


Hi Sean, everyone, 

David Brownell already wrote up a nice article about this at: 
http://www.xml.com/pub/1999/09/conformance/index.html
<http://www.xml.com/pub/1999/09/conformance/index.html>  
which I can't get to at the moment. 

His test driver can be found at http://home.pacbell.net/david-b/xml/
<http://home.pacbell.net/david-b/xml/>  

>From memory: 

On Wed, 17 Nov 1999, Sean Mc Grath wrote: 

> Fully 1.0 Compliant - Non Validating 
> ------------------------------------- 
4. Sun ProjectX 

> Fully XML 1.0 Compliant - Validating 
> ------------------------------------ 
2. Sun ProjectX 

> Non XML 1.0 Compliant - Non-Validating 
> -------------------------------------- 
aelfred 
DataChannel 
Microsoft 
IBM XML4J 
IBM XML4C 


> Non XML 1.0 Compliant - Validating 
> ---------------------------------- 
> nsgmls (C++) 
> xmlproc (Python) 

IBM XML4J 
IBM XML4C (? I think) 

------------- 
BTW, I think a more useful table would include what other features the 
parsers have, rather than just a strict compliance/validating judgement. 

Example features to consider would be: parser size (why I use aelfred), 
parser speed (why XP is a good choice), language supported (Java/C/C++), 
DOM1 support, DOM2 support, SAX support, SAX2 support, namespace support, 
external entities support, memory usage, maximum file size supported, 
and last but not least character set encodings supported. 

. . . Sean (not related =) 



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991118/ddd10a67/attachment.htm
From paul at prescod.net  Thu Nov 18 03:34:07 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:12 2004
Subject: Do SGML and XML co-exist?
References: <383233D8.46BC@hiwaay.net> <m3aeod6lug.fsf@localhost.localdomain> <38335F04.1303@hiwaay.net>
Message-ID: <38336763.506679C7@prescod.net>

Len Bullard wrote:
> 
> That was the danger expressed to Murray in Vancouver, but it looks
> like the survivors figured it out.  Yes, MS or any company including
> the Feds can leave one hanging.  But this is so:  if Jean Paoli
> had NOT come to Vancouver, and certain parties not persuaded the
> IE product managers that SGML was the key to getting six month
> lead on the then dominant browser, that this innovation would
> work where every other form of arm twisting would fail, we
> would be debating this on comp-text-sgml.

I don't believe that. There was a requirement for an e-commerce and data
interchange meta-language. We were there first. The client side (if it
ever materializes) will be gravy. Microsoft probably accelerated the
process but there was a desperate market need for a faster way to
describe data interchange languages than BNF and SGML really should have
been there several years ago but for the stigma and the DTD dependency
issue. 

Admittedly, had Microsoft come out with an XML *competitor*, XML might
have been in trouble. But if they sat on their hands, we would still
need to solve the Internet e-commerce issues with or without them and I
don't see any other proposals for data interchange meta- and schema-
languages.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 03:38:32 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:17:12 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
In-Reply-To: <3.0.32.19991117092816.0152e5f0@pop.intergate.ca>
References: <3.0.32.19991117092816.0152e5f0@pop.intergate.ca>
Message-ID: <14387.24622.910000.445249@menteith.com>

At 17 Nov 1999 09:29 -0800, Tim Bray wrote:
 > What's really happening, near as I can tell, is that C programmers use
 > UTF-8 and Java programmers use UTF-16, regardless of where they're from.

And Perl and Tcl programmers use UTF-8, and Visual Basic, VBScript,
and JScript programmers use UTF-16.  (And Python programmers use a
future version of Python.)

 > Fortunately, this particular conversion is easy and requires no tables. -T.

I'm still not sure I'd want to do it in Visual Basic (but that's my
general reaction to Visual Basic anyway).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 03:42:03 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:17:12 2004
Subject: documenting schemas/DTDs
References: <8D96EDA0AC04D31197B400A0C96C1480811034@ossex1.ossinc.net>
Message-ID: <38337644.5A0EC416@isogen.com>

Peter Saint-Andre wrote:
> 
> Chapter 5 of the XML Schema working draft is a placeholder for
> recommendations regarding the documenting of schemas, and the available
> information on DDML and XSchema for DTDs seems somewhat out of date. What is
> the status of documentation efforts for XML? I'd sure like to have at my
> disposal an "XMLdoc" technology similar to Javadoc....

My personal feeling, based on many years of painful experience
developing and maintaining DTDs of varying scale and complexity and
documenting same (including the original version of IBM's IBM ID Doc
application and the second edition of the HyTime architecture, both
massive documentation projects) is that the only practical way to
develop and manage non-trivial document types is by making the
documentation the primary definition, with the working declarations
extracted from it using some sort of make process.  This is what we did
for both IBM ID Doc (we developed it by writing the reference manual,
which included the working declarations by reference) and HyTime 2nd
edition (the declarations for the meta-DTD are embedded in the source
for the normative text; we wrote a script to extract them and integrate
them with the ungodly tangle of marked sections needed to manage the
run-time configurability of the HyTime DTD, which do not appear in the
main body of the normative text).

If you are are creating DTD-syntax DTDs, the syntax of DTDs is simply
not up to the task of maintaining and managing documentation of any
useful sophistication. This is true for SGML, where you can embed
comments within declarations (essential for documenting attribute lists)
and absolutely true for XML where all comments must be separate
declarations (and you therefore have no hope of reliably binding them to
the declarations they should go with). 

SGML and XML's marked section facility is not up to the task of managing
complexly configured DTDs (even authoring vs. production distinctions
become unworkable very quickly). If you are trying to manage shared
declarations across several derivative DTDs, it is simply impossible.

Given this, the only realistic solution is to use XML documents to
describe the document type and define the details of the declarations
(thus, something that looks a lot like XML Schemas). In an XML context
you can do sophisticated configuration control, your documentation can
be as sophisticated as you need, you can do real modularization, and so
on.

But, no standard markup for representing DTDs will be directly usable
for this task, simply because no matter what the standard says, it will
not meet some significant number of your requirements for a DTD creation
and authoring DTD. This is not a failing of the XML Schema designers, it
is simply a fact, the same fact that guarantees that no industry
standard DTD will be useful for authoring by any given member of that
industry.

This means that *regardless of whether you prefer DTD syntax or XML
Schema*, you will define your own document type and supporting
infrastructure for managing your DTD documentation (by "you" I mean
people doing non-trivial production-quality stuff, not individuals
playing about with XML, for whom simpler solutions are satisfactory). Or
you will soon wish you had.

Note that the focus must be on the *documentation*, not the
declarations. That's because it's the documentation that counts in the
long run. The declarations are so much syntax. Without the documentation
the declarations are useless, but with the documentation, the
declarations can be recreated at will. 

It also means that DTD syntax or XML Schema, it doesn't really matter
because both will be equally easy to create (more or less--schemas will
actually be somewhat harder because they give you more to say and more
syntax you have to worry about, but that's another matter).

The problem, of course, is that building this sort of system is non
trivial--it's certainly more complex than your typical SGML publishing
application. To be complete it requires at least the following
components:

1. A well thought out document type that provides rich documentation
structures that meet your specificat requirements as well as complete
ways to represent declarations at the appropriate level of abstraction
(this may seem easy, but it's actually quite a subtle problem, even when
you are a committee of one).

2. Infrastructure for doing use-by-reference of documentation and DTD
modules so you can manage systems of related DTDs. The current XML
family of specifications offer little help here because they do not
provide a clear or general use-by-ref semantic (although I've seen some
encouraging developments in this area).

3. Extensive editor customization to make creating what will be quite
verbose and complex documents easy and managable.

4. Sophisticated and complex online and print rendering systems to turn
this documentation into something readable.

5. The DTD "make" process itself that generates the working
declarations, whatever form they may take.

My experience suggests that there cannot be a one-size-fits all solution
for this problem. In particular, no XML Schema proposal can solve it
because anything it does with respect to documentation will either be
too little or too general or too restrictive to meet requirements. Even
an architecture-based approach would probably be too restrictive,
although it could get closer to being generally useable.

It is probably possible to develop a good bit of the necessary
infrastructure in a generic way that could be used by many different DTD
documentation document types.  Unfortunately, it's not easy to see how
it could be a money-making proposition and I doubt it fires the
enthusiasm of anyone with open source time on their hands. I would
probably take it on if I had independent wealth because it's actually
one of the more challenging and interesting XML application problem
spaces and the lack of such systems is a significant limiting factor to
the sophistication of the XML solutions that can be built simply because
the DTDs and their documentation become unmanagable without them.

If anyone has a couple million dollars to throw at this problem over the
next year or two, feel free to drop me a line....

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 03:53:58 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun  7 17:17:12 2004
Subject: Parser compliance 
References: <003601bf3070$17ea3a80$53f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <3833786D.C524A9AC@allette.com.au>


David Megginson wrote:

> The DTD has two small but important roles in system implementation: as
> a partial set of structural validation rules and as a partial schema
> for guided authoring (it's nearly always supplemented in both cases).

Agreed.

> Unfortunately, SGML consultancies who knew mainly just DTDS and FOSIs
> were substituting DTD design for data analysis, domain modelling,
> system design, user interface design, and lots of other things for
> which DTDs are woefully inadequate.

Also agreed. However very few SGML people would have used a DTD in domain modelling, system
design or user interface design, so inadequacies in those areas equal SGML's inability to
deliver milk to your doorstep. :-) I don't deny for a second that the ability to base systems
on XML without DTDs is an extremely good thing - it will almost surely make XML the defining
force in computing. The fact remains though that for documents that were created against a
DTD, it is incorrect to declare that it is a myth that validation can tell you what's wrong
with your XML. Depending on the structure (tiny, all empty elements) and the data (must be
tokens from attribute lists), validation may be a perfectly adequate method of uncovering
problems. The further you move from this model, the more you need to supplement the
information availabe from the DTD, as you pointed out above.

> DTDs should have been just part of the solution, not *the* solution.

I still don't see what the other part should have been. It still sounds as though there was
some sort of willful conspiracy or ignorance, but it appears to be based on the fact that we
can do so much more now, so we should have known better then.

> In any case, my message was an explanation of why DTDs have been so
> heavily hyped, not an attack on the idea of DTDs themselves.  DTDs
> were the great Golden Hammer of the SGML consulting world.

Yes, when nails were the only thing that held houses together.


--
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From azly at dsuper.net  Thu Nov 18 04:07:57 1999
From: azly at dsuper.net (Azly NACRO)
Date: Mon Jun  7 17:17:12 2004
Subject: Can't subclass ElementNode 
Message-ID: <38336D82.A0C33EAD@dsuper.net>

Hi,

I've got a java.lang.IllegalAccessError when trying to subclass
"ElementNode".

java.lang.IllegalAccessError: try to access class
com/sun/xml/tree/ParentNode from class CapabilityElement
	at CapabilityElement.appendChild(CapabilityElement.java:88)
	at
com.sun.xml.tree.XmlDocumentBuilder.startElement(XmlDocumentBuilder.java:485)
	at com.sun.xml.parser.Parser.maybeElement(Parser.java:1390)
	at com.sun.xml.parser.Parser.content(Parser.java:1498)
	at com.sun.xml.parser.Parser.maybeElement(Parser.java:1399)
	at com.sun.xml.parser.Parser.parseInternal(Parser.java:491)
	at com.sun.xml.parser.Parser.parse(Parser.java:308)
	at XmlCapabilityAccessor.<init>(XmlCapabilityAccessor.java:55)
	at Test.main(Test.java, Compiled Code)


I'm working with jbuilder3 using jdk1.2.
	java version "1.2"	
	Classic VM (build JDK-1.2-V, native threads)

I've recompile the sun xml package but I still have the same error.

Any ideas what I can do about this? It would be very inconvenient not to
be able to subclass ElementNode.

Azly NACRO
azly@dsuper.net
UQAM (Montreal)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 04:25:41 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:12 2004
Subject: Parser compliance
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <199911180130.TAA00892@bruno.techno.com>
Message-ID: <00d701bf317c$f4699890$eb020a0a@bowstreet.com>

> [Tim Bray:]
> > I have often wondered where this myth arose that validating against
> > a DTD will tell you, in useful real-world terms, "what's wrong with
> > your XML".

Well, I think DTDs and other schemata can be useful (I would have less
error-checking code in FOP if I used a validating parser), but I agree that
a myth has arisen that DTDs (and especially schemata in new schema
languages) do a lot more than they actual do. My favourite myth is that a
schema tells you what an XML document means.

Last week I ran a course at SD99 on practical DTD design and my first slide
was a list of the things a schema *doesn't* do. There's a lot of
myth-busting to be done.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 04:25:43 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:12 2004
Subject: Can't subclass ElementNode
References: <38336D82.A0C33EAD@dsuper.net>
Message-ID: <38337FBB.83F045E1@pacbell.net>

Send your query to Sun.  If compiled using JDK 1.2 "javac", it
should work fine on all JVMs ... but many other versions of "javac"
have bugs.  (And I heard recently something else cropped up.)

Basically, the "appendChild" method is there and public (part
of an interface that's publicly implemented) so you're hitting
a bug somewhere.  Usually it's been "javac" generating bad code.

- Dave

p.s. If you're really desperate for a workaround, you can make
	the superclasses public ... but that's not supported by
	Sun and you can't redistribute such versions.  Though
	maybe the Java Apache project has a version with a
	more reasonable licence.


Azly NACRO wrote:
> 
> Hi,
> 
> I've got a java.lang.IllegalAccessError when trying to subclass
> "ElementNode".
> 
> java.lang.IllegalAccessError: try to access class
> com/sun/xml/tree/ParentNode from class CapabilityElement
>         at CapabilityElement.appendChild(CapabilityElement.java:88)
>         at
> com.sun.xml.tree.XmlDocumentBuilder.startElement(XmlDocumentBuilder.java:485)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1390)
>         at com.sun.xml.parser.Parser.content(Parser.java:1498)
>         at com.sun.xml.parser.Parser.maybeElement(Parser.java:1399)
>         at com.sun.xml.parser.Parser.parseInternal(Parser.java:491)
>         at com.sun.xml.parser.Parser.parse(Parser.java:308)
>         at XmlCapabilityAccessor.<init>(XmlCapabilityAccessor.java:55)
>         at Test.main(Test.java, Compiled Code)
> 
> I'm working with jbuilder3 using jdk1.2.
>         java version "1.2"
>         Classic VM (build JDK-1.2-V, native threads)
> 
> I've recompile the sun xml package but I still have the same error.
> 
> Any ideas what I can do about this? It would be very inconvenient not to
> be able to subclass ElementNode.
> 
> Azly NACRO
> azly@dsuper.net
> UQAM (Montreal)
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 04:31:10 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:12 2004
Subject: documenting schemas/DTDs
References: <8D96EDA0AC04D31197B400A0C96C1480811034@ossex1.ossinc.net> <38337644.5A0EC416@isogen.com>
Message-ID: <010501bf317d$b537f6c0$eb020a0a@bowstreet.com>

> the only practical way to
> develop and manage non-trivial document types is by making the
> documentation the primary definition, with the working declarations
> extracted from it using some sort of make process.

Literate programming, in other words.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lgeorge at gmx.net  Thu Nov 18 04:40:21 1999
From: lgeorge at gmx.net (Lars George)
Date: Mon Jun  7 17:17:12 2004
Subject: Can't subclass ElementNode 
In-Reply-To: <38336D82.A0C33EAD@dsuper.net>
Message-ID: <002601bf317f$4df9d710$0900000a@larsgeorge01>

Hi,

I had the same bug. It boilt down to a problem with the JBuilder. The
compiler produces the wrong bytecode that provokes this error. I have
written a little batch file that compiles the class with the native 1.2
javac and everything worked fine. It only applies to the Sun XML parser as I
have switch to the Oracle one now and even JBuilder has no problems anymore.

However I have not tried to use the swap JDK feature of JBuilder to point to
a separate JDK 1.2 version instead of the shipped one. This may help you as
well.

HTH,

Lars George
Woodgate Research Pty Ltd
Brisbane, Australia

> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Azly NACRO
> Sent: Thursday, 18 November 1999 13:08
> To: xml-dev@ic.ac.uk
> Subject: Can't subclass ElementNode
>
>
> Hi,
>
> I've got a java.lang.IllegalAccessError when trying to subclass
> "ElementNode".
>
> java.lang.IllegalAccessError: try to access class
> com/sun/xml/tree/ParentNode from class CapabilityElement
> 	at CapabilityElement.appendChild(CapabilityElement.java:88)
> 	at
> com.sun.xml.tree.XmlDocumentBuilder.startElement(XmlDocumentBuilde
> r.java:485)
> 	at com.sun.xml.parser.Parser.maybeElement(Parser.java:1390)
> 	at com.sun.xml.parser.Parser.content(Parser.java:1498)
> 	at com.sun.xml.parser.Parser.maybeElement(Parser.java:1399)
> 	at com.sun.xml.parser.Parser.parseInternal(Parser.java:491)
> 	at com.sun.xml.parser.Parser.parse(Parser.java:308)
> 	at XmlCapabilityAccessor.<init>(XmlCapabilityAccessor.java:55)
> 	at Test.main(Test.java, Compiled Code)
>
>
> I'm working with jbuilder3 using jdk1.2.
> 	java version "1.2"
> 	Classic VM (build JDK-1.2-V, native threads)
>
> I've recompile the sun xml package but I still have the same error.
>
> Any ideas what I can do about this? It would be very inconvenient not to
> be able to subclass ElementNode.
>
> Azly NACRO
> azly@dsuper.net
> UQAM (Montreal)
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 04:44:43 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:13 2004
Subject: documenting schemas/DTDs
Message-ID: <3.0.32.19991117202527.014d6b10@pop.intergate.ca>

At 09:45 PM 11/17/99 -0600, W. Eliot Kimber wrote:

>Note that the focus must be on the *documentation*, not the
>declarations. That's because it's the documentation that counts in the
>long run. The declarations are so much syntax. Without the documentation
>the declarations are useless, but with the documentation, the
>declarations can be recreated at will. 

I reproduce Eliot's paragraph in full because it is profoundly true and 
rewards repeated reading.  DTD's and XML Schemas both are *just syntax* 
dammit, and syntax is not interesting.  XML, at the end of the day, is not 
interesting.  Messages that convey meaning are interesting.  Meaning is 
only conveyed by

 (a) running code, or
 (b) human-readable prose.

To generate (a), you have to have (b) first.

End of the story. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 04:46:54 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:13 2004
Subject: History
Message-ID: <3.0.32.19991117204736.01446c00@pop.intergate.ca>

So Len says that it only went over the top because Microsoft liked it.  Len 
is mostly wrong, but he's used to me saying that and sometimes I'm wrong 
when I do.

For the record.  By the end of 1995, anyone with half a brain could see that
HTML was just not up to some of the jobs that people wanted to get done on 
the Web.  In parallel, some of us had been shouting at the SGML crowd from
inside for years that SGML needed radical simplification.  I can remember
like yesterday at the big SGML conference in 93 or 92 or so, standing around
with Steve DeRose and Jean Paoli and Erik Naggum (most XMLers won't remember
him) agreeing that we ought to do this.  But we didn't, then.

I got invited to join the original XML committee because at SGML/Europe
in 1996 in Munich, I gave a closing keynote inviting the crowd to dispense
with 80% of it.

It is to Jon Bosak's immense credit that he (like many of us) not only 
saw the need for simplification but (unlike anyone else) went and hounded
the W3C until it became less trouble for them to give him his committee than
to keep on saying SGML was irrelevant.

Speaking as one of Jon's nominees I am naturally of the opinion that he
couldn't have picked a better group, but I kinda think that any group of
SGML veterans, some of whom had operated large web sites, would have done
about as well.

And then... First off, Microsoft deserves a lot of credit for Getting It way 
before many other allegedly smart industry leaders.  But there were a bunch
of reasons, some of them accidents of history, why it went over the top.
One of them was, people looked at it seriously because Microsoft was onside.
They soon noticed that unlike a lot of other things Microsoft liked, it was
unlikely to be something that Microsoft could control.  

Any simple explanation of XML's success is simply wrong.  Life, and the
Web biz, are complicated.

It was astounding; Jon and I and some of the others made a concentrated
marketing effort starting at the end of 1996 and went shouting off in all
directions about XML.  It was like hurling your entire weight against a 
locked door that turns out not to be there.  The world, more or less, said 
"yeah, OK".

The details make a good story.  But probably entertaining only to 
syntax geeks. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abisheks at india.hp.com  Thu Nov 18 05:18:06 1999
From: abisheks at india.hp.com (Abhishek Srivastava)
Date: Mon Jun  7 17:17:13 2004
Subject: XML Standards
Message-ID: <017801bf3184$156b9780$252f0a0f@india.hp.com>

Hi,

Sorry for the re-post. Since I got no reply, I am reposting it.

I have come across documents which define C++ or Java coding standards.
these documents will outline the style which should be followed while coding 
(things like naming conventions, layout)

Has anyone created such a document for creating XML (naming conventions to be followed in XML, the layout of the document & DTD, Common do's, don'ts and the nevers of XML)?
This document will define the look and feel of our xml documents.
 
I am creating such a document and since I am 3 months old in XML, I'll like someone
with more experience to share his/her views with me.

regards,
Abhishek.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _/               Abhishek Srivastava
   _/                Hewlett Packard ISO       
  _/_/_/   _/_/_/    -------------------   
 _/    /   _/   _/     (Work)   +91-80-2251554 x1190
_/  _/   _/_/_/      (Ip)     15.10.47.37            
        _/           (Url)    http://sites.netscape.net/abhishes/index.html                        
       _/            
                     Work like you don't need the money.
                     Dance like no one is watching.
                     And love like you've never been hurt.
                     --Mark Twain                       
                     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991118/390fe015/attachment.htm
From tgraham at mulberrytech.com  Thu Nov 18 05:36:52 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:17:13 2004
Subject: Parameter Entity Replacement and the XML 1.0 Grammar
In-Reply-To: <4.2.0.58.19991117100310.00bf82c0@pop1.attglobal.net>
References: <4.2.0.58.19991117100310.00bf82c0@pop1.attglobal.net>
Message-ID: <14387.26898.960000.891860@menteith.com>

At 17 Nov 1999 10:24 -0500, G. Ken Holman wrote:
 > Today I started using a validating parser on the source file and it is 
 > choking on the entity declaration.
 > 
 > I immediately thought the new parser I was using was at fault, but thought 
 > I'd check XML 1.0 and saw that perhaps parameter entity references are not 
 > allowed according to the grammar:
...
 > So, my question is:  Does 4.4.8 take precedence over the grammar 
 > productions (the new parser is incorrect), or is the behaviour I am used to 
 > not correct (XT is incorrect)?

4.4.8 also says that "its replacement text is enlarged by the
attachment of one leading and one following space (#x20) character".

...
 > T:\ftemp>type test.ent
 > <!ENTITY % e "wmf"><!--non .gif extension-->
 > <!NOTATION %e; SYSTEM "">
 > <!ENTITY % filename "'abc.%e;'">

This evaluates to "'abc. wmf '".  According to RFC 2396, spaces aren't
allowed in URIs.  Perhaps the parser is giving a not very useful error
message in response to the spaces in the URI.

What happens when you use:

<!ENTITY % filename "'abc.wmf'">


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 07:00:09 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:13 2004
Subject: Parser compliance
In-Reply-To: <Pine.LNX.4.10.9911172059500.16362-100000@tugela.dsl.net>
Message-ID: <Pine.GSU.4.10.9911172246420.4650-100000@netcom2.netcom.com>

On Wed, 17 Nov 1999, Richard Lanyon wrote:
> Not from me, that's for sure. But if people want validation from their XML
> processors (and people do, it would seem, possibly because so many XML
> books spend so much time talking about validity and DTDs), then we'd
> better give it to them or someone else will...

It seems to me that the reason why books and articles talk about
validation so much is the journalists and authors have gotten the idea
that it's important; if you believe the articles, the primary purpose of a
parser is to determine whether or not a document is valid (that idea may
be the result of a surface exposure to parsing theory, since an abstract
parser is in fact a language recognizer).

But in reality, the most a parser can do is syntactic validation; the
majority of applications need to do semantic validation using application
logic, and once you're doing that it's fairly easy for the application to
do syntactic validation at the same time.  Sure, parser-level validation
is a convenience; you can, e.g. do a getFirstChild on some element and be
assured that the child node is of the type you're expecting, but it's only
a convenience; you can always do a getNodeType yourself. Thus the main
roles for a validating parser appear to be in stand-alone syntax checkers
and structure-directed editors.



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



From jjc at jclark.com  Thu Nov 18 07:08:09 1999
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:17:13 2004
Subject: Parameter Entity Replacement and the XML 1.0 Grammar
References: <4.2.0.58.19991117100310.00bf82c0@pop1.attglobal.net> <14387.26898.960000.891860@menteith.com>
Message-ID: <3833A5C7.3705133D@jclark.com>

Tony Graham wrote:
> 
> At 17 Nov 1999 10:24 -0500, G. Ken Holman wrote:
>  > Today I started using a validating parser on the source file and it is
>  > choking on the entity declaration.
>  >
>  > I immediately thought the new parser I was using was at fault, but thought
>  > I'd check XML 1.0 and saw that perhaps parameter entity references are not
>  > allowed according to the grammar:
> ...
>  > So, my question is:  Does 4.4.8 take precedence over the grammar
>  > productions (the new parser is incorrect), or is the behaviour I am used to
>  > not correct (XT is incorrect)?
> 
> 4.4.8 also says that "its replacement text is enlarged by the
> attachment of one leading and one following space (#x20) character".

But not inside a literal entity value. See 4.4.5.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 18 09:48:41 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:13 2004
Subject: Question on reuse of the XML spec
Message-ID: <000001bf31aa$5bd43b20$099918d1@docuverse1>

Does anyone know what the policy is on using the XML spec's contents to
create a rough draft of another spec?  I read through W3C's copyright
policy page but there was nothing about this.

I realize that this is like Trotsky asking to borrow Stalin's good suit
for a rally but it seems like a waste of excellent material to start
from scratch.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 10:11:51 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:13 2004
Subject: SML: The size of the processor is not the issue
In-Reply-To: <m3vh705zs5.fsf@localhost.localdomain>
References: <"Michael Champion"'s message of "Wed, 17 Nov 1999 19:25:32 -0500">
 <001201bf313d$95272580$099918d1@docuverse1>
 <m31z9o7mp2.fsf@localhost.localdomain>
 <01e601bf315b$6d6a9630$f9d18dce@WORKGROUP>
Message-ID: <3.0.6.32.19991118095350.009e2c90@gpo.iol.ie>

Guys,

There is a lot of talk about how trivial it is to add support
for syntactic feature X to an XML processor and how the gains
of removing it in a putative SML are just not worth it.

I believe this is missing the point.

Imagine a world swimming in XML. *Everything* from Spreadsheet
file formats to HTML will be well formed XML.

It follows that a lot of XML processing will revolve around
transforming XML from one form to another.

It is in this space, transforming XML to XML, that the cost
of all XML 1.0 features are paid. Take the most trivial XML
to XML transformation -- the null transformation. Think about
how hard it is do this for arbirtary XML 1.0 documents.

regards,



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 10:11:49 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:13 2004
Subject: Parser compliance
Message-ID: <3.0.6.32.19991118093704.009e1ba0@gpo.iol.ie>

>[Tim Bray:]
>> I have often wondered where this myth arose that validating against
>> a DTD will tell you, in useful real-world terms, "what's wrong with
>> your XML".
>
[Steve Newcomb]
>I have often wondered where this myth arose that DTDs are somewhere
>between evil and useless.

Probably from the World Wide Web which changed the world in spite
of rather than because of, the existence of a DTD for HTML.

I sometimes hear SGML people claiming that SGML is a runaway
success because the Web is an SGML application. Insofar as
the Web is an SGML an application it ain't go no DTD in
any meaninful SGML sense.

regards,



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rgl at decisionsoft.com  Thu Nov 18 10:44:48 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:13 2004
Subject: Parser compliance
In-Reply-To: <199911180130.TAA00892@bruno.techno.com>
Message-ID: <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>

On Wed, 17 Nov 1999, Steven R. Newcomb wrote:

> I have often wondered where this myth arose that DTDs are somewhere
> between evil and useless.  It's baffling that this myth arises when
> there's nothing better than, or even as good as DTDs.

It seems to me that the problem lies in what exactly DTDs are used /for/.
Basically, DTDs are used for checking the structure of a document. While
this is doubtless important, it seems to me to be curious that what is
essentially an error-checking mechanism is the first thing that many
people learn about XML. This in turn is because the important bit of XML
 - viz designing hierarchical structures - becomes conflated in many
people's minds with the syntax you use to error-check your structures.
This is particularly worrying because in many cases the error-handling
will be best dealt with by something familiar with the /semantics/ of the
structure (i.e. a specific XML application) rather than by an XML parser.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 10:49:59 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:17:13 2004
Subject: Question on reuse of the XML spec
In-Reply-To: <000001bf31aa$5bd43b20$099918d1@docuverse1>
References: <000001bf31aa$5bd43b20$099918d1@docuverse1>
Message-ID: <19991118054941.B26283@w3.org>

On Thu, Nov 18, 1999 at 01:50:32AM -0800, Don Park wrote:
> Does anyone know what the policy is on using the XML spec's contents to
> create a rough draft of another spec?  I read through W3C's copyright
> policy page but there was nothing about this.
> 
> I realize that this is like Trotsky asking to borrow Stalin's good suit
> for a rally but it seems like a waste of excellent material to start
> from scratch.

  Don, 

 since the Copyright is a legal document we have put a FAQ online

   http://www.w3.org/Consortium/Legal/IPR-FAQ.html

if this doesn't cover your question, tell me I will try to get
more specific informations in your use case.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ht at cogsci.ed.ac.uk  Thu Nov 18 11:02:30 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:17:13 2004
Subject: Why validate? (was Re: Parser compliance)
In-Reply-To: David Megginson's message of "17 Nov 1999 13:10:15 -0500"
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain>
Message-ID: <f5byabwukos.fsf_-_@cogsci.ed.ac.uk>

Maybe I was overly influenced by the fact that my first exposure to
pointy brackets was in the context of SGML, but I think validation is
pretty fundamental.  A DTD is like a contract, it helps both
clients and service providers to maintain a satisfactory working
relationship.

1) As a client, I validate to save wasted round-trips when service providers
bounce my submissions for syntactic errors;

2) As a service provider, I validate to save resources, at two levels:

  2a) During application development, the earlier phases of system
      structure are much simpler and clearer because they don't mix
      (syntactic) error detection and basic structure construction;

  2b) During application operation, syntactic errors are detected and
      reported in a standard way likely to be familiar to clients,
      reducing handholding requirements.
 
In my own development work, I find (2a) particularly pertinent,
whether the applications involved are programs OR stylesheets.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 11:18:21 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:13 2004
Subject: documenting schemas/DTDs
In-Reply-To: "W. Eliot Kimber"'s message of "Wed, 17 Nov 1999 21:45:08 -0600"
References: <8D96EDA0AC04D31197B400A0C96C1480811034@ossex1.ossinc.net> <38337644.5A0EC416@isogen.com>
Message-ID: <m3n1sc59sn.fsf@localhost.localdomain>

"W. Eliot Kimber" <eliot@isogen.com> writes:

> My personal feeling, based on many years of painful experience
> developing and maintaining DTDs of varying scale and complexity and
> documenting same (including the original version of IBM's IBM ID Doc
> application and the second edition of the HyTime architecture, both
> massive documentation projects) is that the only practical way to
> develop and manage non-trivial document types is by making the
> documentation the primary definition, with the working declarations
> extracted from it using some sort of make process.  

[snip]

> If you are are creating DTD-syntax DTDs, the syntax of DTDs is simply
> not up to the task of maintaining and managing documentation of any
> useful sophistication. 

I agree very strongly with Eliot, perhaps because we both have a lot
of experience in creating (rather than just processing) user
documentation.

Even a schema spec that allowed very rich documentation in each
declaration would be at best the equivalent of JavaDoc, and that's not
good enough.  The problem (and this is a classic in tech writing) is
that the optimal way to arrange information for a human reader is
rarely the optimal way to arrange information for technical
implementation, and vice versa.

Except in very rare circumstances, for example, any tech writer who
structures a user manual around the UI ("Chapter 1: the File Menu")
deserves to be fired without severance pay, ritually humiliated in
front of the whole office, and rolled all the way out to the parking
lot in a garbage can -- the fact that they aren't is a testimony to
the shortage of even minimally competent tech writers out there.

Personally, I deserve the same treatment for never having provided a
proper SAX 1.0 spec -- I'll try to remedy that situation before
everyone figures out how to send a garbage can through e-mail.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 11:33:34 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:13 2004
Subject: SML: The size of the processor is not the issue
In-Reply-To: Sean Mc Grath's message of "Thu, 18 Nov 1999 09:53:50 +0000"
References: <"Michael Champion"'s message of "Wed, 17 Nov 1999 19:25:32 -0500"> <001201bf313d$95272580$099918d1@docuverse1> <m31z9o7mp2.fsf@localhost.localdomain> <01e601bf315b$6d6a9630$f9d18dce@WORKGROUP> <3.0.6.32.19991118095350.009e2c90@gpo.iol.ie>
Message-ID: <m3k8ng593l.fsf@localhost.localdomain>

Sean Mc Grath <digitome@iol.ie> writes:

> It is in this space, transforming XML to XML, that the cost
> of all XML 1.0 features are paid. Take the most trivial XML
> to XML transformation -- the null transformation. Think about
> how hard it is do this for arbirtary XML 1.0 documents.

That's simply a problem of underspecification: XML 1.0 provides a
syntax, but for the most part, it doesn't say what in that in that
syntax is signal (such as character data) and what is noise (such as
whitespace in a start tag).

APIs defacto make the signal/noise distinction for you.  If you're
accessing an XML document through SAX, all you have to worry about in
the transform is the following:

1. notation decls
2. unparsed entity decls
3. elements
4. attributes and their values
5. character data
6. whitespace in element content (which you can treat as character
   data)
7. processing instructions

That's pretty good, really.  Writing an identity transform with SAX in
Java takes only a few screens of code and can be managed in 15 minutes 
by any competent, intermediate-level programmer who knows the domain
(a good coder can do it in 5).

On a more formal level, the Infoset goes to great care to make the
signal/noise distinction that's missing from XML 1.0, and Canonical
XML builds further on the Infoset.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 12:00:10 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:13 2004
Subject: SML: The size of the processor is not the issue
Message-ID: <3.0.6.32.19991118114931.00939920@gpo.iol.ie>

>Sean Mc Grath <digitome@iol.ie> writes:
>
>> It is in this space, transforming XML to XML, that the cost
>> of all XML 1.0 features are paid. Take the most trivial XML
>> to XML transformation -- the null transformation. Think about
>> how hard it is do this for arbirtary XML 1.0 documents.
>
[David Megginson]
>That's simply a problem of underspecification: XML 1.0 provides a
>syntax, but for the most part, it doesn't say what in that in that
>syntax is signal (such as character data) and what is noise (such as
>whitespace in a start tag).
>
>APIs defacto make the signal/noise distinction for you.

On whose authority? I agree they make the distinction, I was
not aware that there was a global consensus on where that
distinction lies.

Are you saying that a SAX based
XML to XML transformation will generate an XML document
that looses nothing that anyone cares about in the
original?

Everyone is happy to have the parsed entities expanded inline.
Everybody is happy to loose their internal document type declaration
subsets.
Everybody is happy to have #IMPLIED attributes inlined.
etc. etc.

regards,



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



From robin at isogen.com  Thu Nov 18 13:00:29 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:13 2004
Subject: documenting schemas/DTDs
In-Reply-To: <m3n1sc59sn.fsf@localhost.localdomain>
Message-ID: <Pine.GSO.3.96.991118065027.13911G-100000@grind>

With respect to Eliot Kimber's endorsement of literate
programming style (applied to SGML/XML applications), and
David Megginson's "strong agreement" with Eliot's sentiments:

I have collected some references to experience with
"Literate Programming with SGML and XML" in:

   http://www.oasis-open.org/cover/xmlLitProg.html

- Robin Cover

-----------

On 18 Nov 1999, David Megginson wrote:

> "W. Eliot Kimber" <eliot@isogen.com> writes:
> 
> > My personal feeling, based on many years of painful experience
> > developing and maintaining DTDs of varying scale and complexity and
> > documenting same (including the original version of IBM's IBM ID Doc
> > application and the second edition of the HyTime architecture, both
> > massive documentation projects) is that the only practical way to
> > develop and manage non-trivial document types is by making the
> > documentation the primary definition, with the working declarations
> > extracted from it using some sort of make process.  
> 
> [snip]
> 
> > If you are are creating DTD-syntax DTDs, the syntax of DTDs is simply
> > not up to the task of maintaining and managing documentation of any
> > useful sophistication. 
> 
> I agree very strongly with Eliot, perhaps because we both have a lot
> of experience in creating (rather than just processing) user
> documentation.
[...]


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 13:28:11 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:13 2004
Subject: Why validate? (was Re: Parser compliance)
In-Reply-To: ht@cogsci.ed.ac.uk's message of "18 Nov 1999 11:02:27 +0000"
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain> <f5byabwukos.fsf_-_@cogsci.ed.ac.uk>
Message-ID: <m3hfik53sa.fsf@localhost.localdomain>

ht@cogsci.ed.ac.uk (Henry S. Thompson) writes:

> Maybe I was overly influenced by the fact that my first exposure to
> pointy brackets was in the context of SGML, but I think validation is
> pretty fundamental.

I don't think that anyone is arguing against the usefulness of
validation -- Tim's point is DTDs and other formal schemas alone
supply only a small subset the validation necessary for any
real-world information exchange.

> A DTD is like a contract, it helps both clients and service
> providers to maintain a satisfactory working relationship.

It's a very simply contract, though; consider the following DTD:

 <!ELEMENT song (title, composer)>
 <!ELEMENT title (#PCDATA)>
 <!ELEMENT composer (#PCDATA)>

Here's a document that's valid according to that DTD, and that doesn't 
fiddle with the DTD in its internal subset:

 <?xml version="1.0"?>
 <!DOCTYPE song SYSTEM "song.dtd">
 <song>
  <title>David Bowie</title>
  <composer>Let's Dance</composer>
 </song>

As Eliot, Tim, and I have all mentioned (in different contexts), the
primary contract *has* to be the human readable documentation, even
though the DTD is useful for detecting a certain subset of 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 18 13:34:04 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:14 2004
Subject: Parser compliance
In-Reply-To: <Pine.GSU.4.10.9911172246420.4650-100000@netcom2.netcom.com
 >
References: <Pine.LNX.4.10.9911172059500.16362-100000@tugela.dsl.net>
Message-ID: <199911181333.IAA07328@hesketh.net>

At 10:59 PM 11/17/99 -0800, Eric Bohlman wrote:
>On Wed, 17 Nov 1999, Richard Lanyon wrote:
>> Not from me, that's for sure. But if people want validation from their XML
>> processors (and people do, it would seem, possibly because so many XML
>> books spend so much time talking about validity and DTDs), then we'd
>> better give it to them or someone else will...
>
>It seems to me that the reason why books and articles talk about
>validation so much is the journalists and authors have gotten the idea
>that it's important; if you believe the articles, the primary purpose of a
>parser is to determine whether or not a document is valid (that idea may
>be the result of a surface exposure to parsing theory, since an abstract
>parser is in fact a language recognizer).

I think that a large part of the reason book and article writers have
focused on DTDs is their large (and relatively difficult) place in the XML
1.0 specification and the need to explain to people some kind of
technical-sounding 'how' of creating new vocabularies.

In my latest book (not yet published), I spent a lot of time talking about
things like notations, parameter entities, unparsed entities, and all the
'black art' stuff involved in DTDs and validation.  I covered the material
in that kind of depth not because it's in massive demand (as far as I can
tell) but because it's typically under-covered in other XML books,
including several of my own.

On the other hand, I spent a lot of time explaining the need to create
human-readable documentation for XML, whether or not it uses validation,
and about the kinds of things XML developers need to make clear to all
programmers implementing their work - like whether or not external
entities, external DTDs, and namespaces will be used.  I also closed with a
description of a markup universe where DTDs and schemas are ignored
completely, and information is passed on a role-to-role basis without any
master plan or concern for validation.  Both approaches are equally
plausible (to me) as ways around the pros and cons of DTDs and the
varieties of parsers available.

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 18 13:33:27 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:14 2004
Subject: documenting schemas/DTDs
In-Reply-To: <m3n1sc59sn.fsf@localhost.localdomain>
References: <"W. Eliot Kimber"'s message of "Wed, 17 Nov 1999 21:45:08 -0600">
 <8D96EDA0AC04D31197B400A0C96C1480811034@ossex1.ossinc.net>
 <38337644.5A0EC416@isogen.com>
Message-ID: <199911181332.IAA07285@hesketh.net>

At 06:16 AM 11/18/99 -0500, David Megginson wrote:
>"W. Eliot Kimber" <eliot@isogen.com> writes:
>> My personal feeling, based on many years of painful experience
>> developing and maintaining DTDs of varying scale and complexity and
>> documenting same (including the original version of IBM's IBM ID Doc
>> application and the second edition of the HyTime architecture, both
>> massive documentation projects) is that the only practical way to
>> develop and manage non-trivial document types is by making the
>> documentation the primary definition, with the working declarations
>> extracted from it using some sort of make process.  
>[snip]
>> If you are are creating DTD-syntax DTDs, the syntax of DTDs is simply
>> not up to the task of maintaining and managing documentation of any
>> useful sophistication. 
>
>I agree very strongly with Eliot, perhaps because we both have a lot
>of experience in creating (rather than just processing) user
>documentation.

I'll agree with both of you as well, though with the caveat that
conventions can make comments much more useful within DTDs.  XML Authority
does a little of this, but there's a lot more that can be done if people
are willing to take the time or develop tools.  So far, no one I've seen
has really invested in this, at least in a public way.

>Even a schema spec that allowed very rich documentation in each
>declaration would be at best the equivalent of JavaDoc, and that's not
>good enough.  The problem (and this is a classic in tech writing) is
>that the optimal way to arrange information for a human reader is
>rarely the optimal way to arrange information for technical
>implementation, and vice versa.

It seems like the schema spec might do well to provide a means of including
schema information inside of the documentation, rather than in a separate
box that goes along with the declarations (and which might never get filled
out.)  A transformation between this documentation-centric format and a
more machine-centric format probably wouldn't be that hard to create.

Speaking of these transforms, does anyone else think the schema spec is a
good target for profiling and simplification?

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 18 13:38:02 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:17:14 2004
Subject: schemas in use
Message-ID: <199911181337.IAA07521@hesketh.net>

If anyone is creating or using tools for processing XML Schema, XML-Data,
XDR, DCD, SOX, or DDML schemas, could you please contact me (privately)?
I'm attempting to build a list.

I'm not interested (today) in people building schemas - only in the tools
people are building to process schemas.

Thanks!

Simon St.Laurent
XML: A Primer, 2nd Ed.
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Thu Nov 18 14:01:20 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:17:14 2004
Subject: Why validate?
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain> <f5byabwukos.fsf_-_@cogsci.ed.ac.uk>
Message-ID: <005b01bf31cd$e482d760$3815b0cf@tomshp>

Thinking about "why validate", why did HTML become so wide-spread so fast?
I think that a big part of the reason is that almost anyone could learn how
to write usable pages quickly and with no formal training or programming
experience.  If validation or even DTDs without validation had been
required, most of those sites would never have sprouted up.  You looked at
the source for a page, and you could see the whole scheme behind HTML in a
few glances.  I had never heard of markup languages, and I remember thinking
"what an interesting way to do things".

And then the browsers were somewhat tolerant of mistakes, too.  I remember
writing quite a few HTML pages or fragments, which I did by copying ideas
from other pages.  And they worked!  The first few times I looked at the
HTML standard, I was revolted and couldn't get anyting useful out of it.

The same thing has been happening with css, although it's harder to pick up
on the fly.

Now, it's true you probably can't design a big e-commerce site these days by
just winging it this way.  Nor complex document managment systems.  But this
ease-of-use, fault-tolerant aspect is likely to be of major importance in
building wide usage and acceptance of XML (or "SML").  And this aspect does
not include validation and probably not DTDs either.  If we have developed a
truly good system in XML, it will be able to adapt well to both ends of the
spectrum.  HTML wasn't up to this.  XML, I think, has the possiblity of
being up to it.

Tom Passin

From: Henry S. Thompson <ht@cogsci.ed.ac.uk>


> Maybe I was overly influenced by the fact that my first exposure to
> pointy brackets was in the context of SGML, but I think validation is
> pretty fundamental.  A DTD is like a contract, it helps both
> clients and service providers to maintain a satisfactory working
> relationship.
>
> 1) As a client, I validate to save wasted round-trips when service
providers
> bounce my submissions for syntactic errors;
>
> 2) As a service provider, I validate to save resources, at two levels:
>
>   2a) During application development, the earlier phases of system
>       structure are much simpler and clearer because they don't mix
>       (syntactic) error detection and basic structure construction;
>
>   2b) During application operation, syntactic errors are detected and
>       reported in a standard way likely to be familiar to clients,
>       reducing handholding requirements.
>
> In my own development work, I find (2a) particularly pertinent,
> whether the applications involved are programs OR stylesheets.
>
> ht
> --



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



From BBerck at ESPS.com  Thu Nov 18 14:25:08 1999
From: BBerck at ESPS.com (Ben Berck)
Date: Mon Jun  7 17:17:14 2004
Subject: Clarification on "Burnt by MSXML.DLL"
Message-ID: <4139ED560536D3118F100008C7F36E451A8D4F@HQMAIL>

In a previous message, I wrote:
>>We have been burnt with relying on MSXML.DLL.

To clarify, the "Pre-DOM" C++ XML Parser seems to work fine.  

However, this requires that our clients have a particular version of IE
installed on their machines.  My company's tech support staff are constantly
getting calls about why something doesn't work.  Their problem is they don't
have an MSXML.DLL on their system!

The answer is: 
"You have to have IE4, SP1 installed."  This seems to upset a lot of our
corporate clients, who have chosen Netscape as their browser, and they don't
want to have anybody installing newer versions of IE.
Hence, "burnt."


SIDE NOTE:
In another project, I'm now using the IE5 DOM and have found it very easy to
use, especially with the VC++ 6.0 #import feature of the DLL. My only
complaint is that the error messages returned are almost always E_FAIL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991118/3afbaa82/attachment.htm
From jmcdonou at library.berkeley.edu  Thu Nov 18 14:24:17 1999
From: jmcdonou at library.berkeley.edu (Jerome McDonough)
Date: Mon Jun  7 17:17:14 2004
Subject: Parser compliance
In-Reply-To: <m3so245ypz.fsf@localhost.localdomain>
References: <Marcus Carr's message of "Thu, 18 Nov 1999 11:09:15 +1100">
 <3.0.32.19991117093112.01aad530@pop.intergate.ca>
 <m37ljh6lbs.fsf@localhost.localdomain>
 <383343AA.EBB9B115@allette.com.au>
Message-ID: <199911181423.JAA27072@westnet.com>

At 09:18 PM 11/17/99 -0500, David Megginson wrote:
>The DTD has two small but important roles in system implementation: as
>a partial set of structural validation rules and as a partial schema
>for guided authoring (it's nearly always supplemented in both cases).
>

Limiting a discussion of DTD's importance to system implementation, though,
strikes me as somewhat unfair.  Although perhaps not the case for many
commercial endeavors, DTDs provided a focus for many efforts designed
to provide a standard for document exchange.  If it weren't for DTDs, 
projects like EAD, TEI, and DDI would have had a much more difficult
time getting where they going as quickly as they did.  Granted the exact
mechanism didn't have to be DTDs, but DTDs did help a lot of people,
including me, start focusing on structure and really paying attention to
issues of document analysis in a way that I don't think would have happened
otherwise.


Jerome McDonough -- jmcdonou@library.Berkeley.EDU  |  (......)
Library Systems Office, 386 Doe, U.C. Berkeley     |  \ *  * /
Berkeley, CA 94720-6000    (510) 642-5168          |  \  <>  /
"Well, it looks easy enough...."                   |   \ -- /  SGNORMPF!!!
         -- From the Famous Last Words file        |    ||||

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



From schampeo at hesketh.com  Thu Nov 18 14:42:25 1999
From: schampeo at hesketh.com (Steven Champeon)
Date: Mon Jun  7 17:17:14 2004
Subject: History
In-Reply-To: <3.0.32.19991117204736.01446c00@pop.intergate.ca>
Message-ID: <Pine.LNX.3.95.991118093135.9735A-100000@wasabi.hesketh.net>

On Wed, 17 Nov 1999, Tim Bray wrote:
> For the record.  By the end of 1995, anyone with half a brain could see that
> HTML was just not up to some of the jobs that people wanted to get done on 
> the Web.  In parallel, some of us had been shouting at the SGML crowd from
> inside for years that SGML needed radical simplification.  I can remember
> like yesterday at the big SGML conference in 93 or 92 or so, standing around
> with Steve DeRose and Jean Paoli and Erik Naggum (most XMLers won't remember
> him) agreeing that we ought to do this.  But we didn't, then.

Erik Naggum was the moderator (after a fashion) of comp.text.sgml, FWIW.
I learned more from Erik about how to manage a community of hard-headed
geeks than I've learned from anyone before or since.

The other thing to remember about SGML (in addition to its complexity,
which XML is supposed to answer) is that although the structure and
storage problems had been more or less solved, the display and
presentation problems remained more or less intractable. Author/Editor,
the application we used to markup documents at the end of a lengthy
paper->.sgm conversion process, had /some/ support for styling, using
a proprietary scheme-based language. I'd heard nightmarish reports of
the difficulties inherent in mastering FOSI, from others in the NC SGML
Users Group. Panorama was two years late in delivering Web-based SGML.

And in the meantime, HTML was easy to learn, easy to use, and showed
up in all its styled glory in any browser you chose. And it just got
"better", in terms of what it could do in that direction. It just never
got better in terms of what you could do structurally. 

Is it any wonder that HTML was doomed? It solved, in a few short months,
the display problems that plagued SGML for ten years, and subsequently
ignored its roots in a rigorous, structure-oriented language.

Ask any Web developer which "tags" they know. Many of them couldn't tell
you two alternatives to <B> and <I>, or what the <DIR> "tag" does. But
every last one knows the vagaries of TABLE, FRAMESET, and <BR CLEAR=ALL>.

I sure hope that the forthcoming browsers choose to focus on support for
XML+CSS, so we can actually have browsers that support both structure /and/
style when rigor is returned to the Web.

Steve



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



From Dapeng.Wang at Dresdner-Bank.com  Thu Nov 18 16:22:01 1999
From: Dapeng.Wang at Dresdner-Bank.com (Wang, Dapeng)
Date: Mon Jun  7 17:17:14 2004
Subject: Schema Tutorial
Message-ID: <F39260401A4FD311BB6700805FA7821BE719F5@ffz00zad.wwz1me.mail.dresdner.net>

Hi,

does anyone know any good tutorials about XML Schema?

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



From Bruce.Duffy at westgroup.com  Thu Nov 18 16:31:37 1999
From: Bruce.Duffy at westgroup.com (Duffy, Bruce)
Date: Mon Jun  7 17:17:14 2004
Subject: What's the current status of SAX2?
Message-ID: <27CD34D68C7DD211A68A0004AC38272A023ED43E@elizabeth.int.westgroup.com>


What's the status of SAX2?  The most recent posting I've
seen on xml-dev was in June.  Is SAX2 still alive?

	Bruce Duffy

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



From Marcus.Bernhardson at nokia.com  Thu Nov 18 16:59:00 1999
From: Marcus.Bernhardson at nokia.com (Marcus.Bernhardson@nokia.com)
Date: Mon Jun  7 17:17:14 2004
Subject: XSL-question
Message-ID: <9524EA4E18D6D2119FEA0008C7C5A0062BCE53@lneis01nok>

Hello there!

Im new to this list (and pretty new to XML/XSL...) and i hope that its ok to
ask a question about XSL here. Please tell me if Im at the wrong place.
I have a very anoying problem i cant solve using XSL with IE5.

I have a xml-file and i wanna list the info in it and sort/filter it
depending on how you select. I use javascript in a html file for selecting
sorting/filtering.

I wanna be able to use a global variable or function to use with the
"select" and "order-by" statements. It doesnt seem to work though.


my XML-file looks something like this:

<root>
 <element>
 	<childelement1/>
	<childelement2/>
	<childelement3/>
 </element>
 
 <element>
 	<childelement1/>
	<childelement2/>
	<childelement3/>
 </element>

 etc...

</root>


I wanna sort all elements in a table so my XSL-file looks something like
this:

<table>
 <xsl:for-each select="root/element" order-by="+childelement2">
  <tr>
   <td>
    <xsl:value-of select="childelement1"/>
   </td>
   <td>
    <xsl:value-of select="childelement2"/>
   </td>
   <td>
    <xsl:value-of select="childelement3"/>
   </td>
 </tr>
 </xsl:for-each>
</table>

When I sort with order-by I wanna use a variable or a function that returns
the sortingcriteria. I cant get it to work, is it possible?

What I mean is that I wanna do something like this:

* with a variable called selectedSort that contains the string
'childelement1', 'childelement2' or 'childelement3':
<xsl:for-each select="root/element" order-by="+selectedSort">
or
* with a function that returns the string 'childelement1', 'childelement2'
or 'childelement3':
<xsl:for-each select="root/element" order-by="+selectedSort()">

If this would work then i could use 1 XSL-file instead of 1 for every
sorting/filtering combination (would be many....). 


When i filter i do like this:
 <xsl:for-each select="root/element[childelement= 'criteria1']"
order-by="+childelement1">

I have same problem here. I wanna be able to do something like this:

<xsl:for-each select="root/element[childelement1= selectedCriteria]"
order-by="+childelement1">
or
<xsl:for-each select="root/element[childelement1= selectedCriteria()]"
order-by="+childelement1">


I would be forever thankful if there a nice person out there who could help
me solving this. Or atleast tell me if its possible while using IE5.

Thanks/
Marcus


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



From robin at isogen.com  Thu Nov 18 17:22:42 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:14 2004
Subject: Why validate? (was Re: Parser compliance)
Message-ID: <Pine.GSO.3.96.991118111535.13911K-100000@grind>

While agreeing that SGML/XML DTD syntax is of limited value
in supporting "validation," I think David Megginson and
Tim Bray have somewhat short-changed the notion of 
declarative, constraint-based (ontologic/relational) semantics
and corresponding (generalized, middle-tier) machine
processing of constraint-based semantics within the "markup"
framework.  I'm speaking of how things could be, not how
they were (ISO 8879:1986) and are (XML 1.0) given
the expressiveness of DTDs.

It's true that SGML/XML DTDs provide almost *no* support
for expression and validation of semantic integrity constraints.
I've written on this because misunderstandings abound (see, for
example http://www.oasis-open.org/cover/xmlAndSemantics.html).

It's probably also true that some SGML practitioners placed
too much weight on DTD design, when other analysis and design
methodologies would have been more appropriate to the
enterprise problem, as Megginson says:

> Unfortunately, SGML consultancies who knew mainly just
> DTDS and FOSIs were substituting DTD design for data 
> analysis, domain modelling, system design, user interface
> design, and lots of other things for which DTDs are 
> woefully inadequate.

I would add to this "requirements engineering" and a number
of other disciplines followed in modern object-oriented
analysis and design frameworks.  The most critical aspect
in any analysis/design/modelling effort is getting the
semantics "right."  DTDs just don't help much in this
connection; if anything, they are a distraction and
frequently a detriment; they impose serious and
"unnatural" constraints upon a data modelling process
(the world is *not* hierarchical or serialized; attributes
*do* have complex values; relationships *do* admit of
semantic constraint properties; etc.)   Personally, I think
SGML's flat-out aversion to semantics was a mistake,
though it represents an understandable position in the
world of "paper print publishing."

On the other hand, I find the current XML Schema Definition
Language endeavor very well motivated with respect to the
goal of "defining datatypes" (an "extensible datatype system")
for use in the markup context.  I am particularly optimistic
about the goal of supporting "user-defined datatypes"
(generated datatypes built upon axiomatic ones, via 
construction rules).  A schema definition language having
access to these datatype declaration facilities, together
with a general schema-validation processor, should provide
the basis for some semantic processing -- which has always
been anathema to the "SGML" view of the world.

In this connection I am happy to see the words "meaning"
and "relationships" in the W3C draft spec:

  The purpose of an XML Schema: Structures schema
  is to define and describe a class of XML documents by 
  using these constructs to constrain and document the
  MEANING, usage and RELATIONSHIPS of their constituent
  parts: datatypes, elements and their content, 
  attributes and their values, entities and their contents
  and notations.

We should be able to say formally what we "mean" by an
<ISBN> (modulo the checksum, perhaps) and a <date>. At
that point, a schema processor will set off alarms if
we say "<date>smelly socks</date>".  Analogous to
what we can say now at the meta-level: "What do you
'mean' by an XML document?" "I 'mean' something
that 'matches the production [1] document'.  Machines
can understand "meaning" at this level, without
the prose documentation (useful to humans).

David also said:

> The DTD has two small but important roles in system
> implementation: as a partial set of structural validation
> rules and as a partial schema for guided authoring
> (it's nearly always supplemented in both cases).

I think DTDs (with all their weaknesses) do more than just
"two small" things.  XML Schemas, to the extent that they
do more than simply mirror DTD notions in instance syntax,
will do even more.   Some sample use cases are described in
the XML Schema requirements document (see
http://www.w3.org/TR/NOTE-xml-schema-req), for example
"Use schema to help [sensible] query formulation and 
[query] optimization" -- a function which DTDs can currently
support today.

Finally:

> As Eliot, Tim, and I have all mentioned (in different
> contexts), the primary contract *has* to be the 
> human readable documentation, even though the DTD is 
> useful for detecting a certain subset of problems.

I don't see the benefit of driving a wedge between "primary"
and its opposite: it depends upon perspective.  EBNFs,
XSDs, DTDs (or any grammar) may be viewed as human readable
documentation, and in some contexts, they have primacy
(contractually) over the informal prose.  Both are normally
necessary.

Still, as Len might say: "formal semantics is hard,
syntax is easy, now get (back) to work."

For anyone whose mind is not already made up on the
matter of generalized processing of (e.g., 'business logic') 
semantics in the markup context, see:

  http://www.cs.utexas.edu/users/mfkb/related.html
  http://www.oasis-open.org/cover/brml.html
  http://www.oasis-open.org/cover/xol.html
  http://www.oasis-open.org/cover/xml.html#xml-ontology

- Robin Cover


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



From gkholman at CraneSoftwrights.com  Thu Nov 18 17:31:42 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:17:15 2004
Subject: XSL-question
In-Reply-To: <9524EA4E18D6D2119FEA0008C7C5A0062BCE53@lneis01nok>
Message-ID: <4.2.0.58.19991118122428.00a52cd0@pop1.attglobal.net>

At 99/11/18 18:58 +0200, Marcus.Bernhardson@nokia.com wrote:
>Im new to this list (and pretty new to XML/XSL...) and i hope that its ok to
>ask a question about XSL here. Please tell me if Im at the wrong place.

A better place is:

  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

>I have a very anoying problem i cant solve using XSL with IE5.
>...
>When I sort with order-by I wanna use a variable or a function that returns
>the sortingcriteria. I cant get it to work, is it possible?

Such a criterion is available using W3C XSLT, not IE5 XSL ... with W3C XSLT 
you can specify a sort key based on a function.

>What I mean is that I wanna do something like this:
>
>* with a variable called selectedSort that contains the string
>'childelement1', 'childelement2' or 'childelement3':
><xsl:for-each select="root/element" order-by="+selectedSort">

Oh.  I'm not really sure what you are asking for, then.

>* with a function that returns the string 'childelement1', 'childelement2'
>or 'childelement3':
><xsl:for-each select="root/element" order-by="+selectedSort()">
>
>If this would work then i could use 1 XSL-file instead of 1 for every
>sorting/filtering combination (would be many....).

Have you examined using general entities (but may not work in IE5) to 
parameterize the encoding of attributes and sub-elements?

>When i filter i do like this:
>  <xsl:for-each select="root/element[childelement= 'criteria1']"
>order-by="+childelement1">
>
>I have same problem here. I wanna be able to do something like this:
>
><xsl:for-each select="root/element[childelement1= selectedCriteria]"
>order-by="+childelement1">
>or
><xsl:for-each select="root/element[childelement1= selectedCriteria()]"
>order-by="+childelement1">

Same answer from me ... such parameterization as I *think* you've described 
isn't possible in XSLT.  But, I think if you were to parameterize the 
*stylesheet markup* instead of trying to parameterize *stylesheet 
behaviour*, you will get what you are looking for.

Also, I expect you want to do "//element[..." to choose from all elements 
with the given predicate (which is not quite what you are asking for).

I hope this helps.

................... Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


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



From robin at isogen.com  Thu Nov 18 17:41:34 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:15 2004
Subject: Schema Tutorial
In-Reply-To: <F39260401A4FD311BB6700805FA7821BE719F5@ffz00zad.wwz1me.mail.dresdner.net>
Message-ID: <Pine.GSO.3.96.991118113821.13911L-100000@grind>


I keep a collection of references in "XML Schemas"
at:

  http://www.oasis-open.org/cover/schemas.html

-rcc

---------------------------------------------------------

On Thu, 18 Nov 1999, Wang, Dapeng wrote:

> Hi,
> 
> does anyone know any good tutorials about XML Schema?
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 17:57:37 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:15 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
References: <3.0.32.19991117162449.01abfa10@pop.intergate.ca>
Message-ID: <38343DFF.99390CD2@pacbell.net>

Tim Bray wrote:
> 
> The performance is good enough that in Lark, the limiting factor was
> my lousy input buffering, not the character class checking; and Lark
> was always in the top half of the performance table. -Tim

I think that's pretty typical.  I've profiled several parsers by now,
and character class checking hasn't been a major issue ... usually
one or two percentage points CPU time for testing whether a character
works in a name (first/rest) or not.

The technique I used in Sun's parser may be good for many folk to steal.
It involves using the standard Character.getType() method (which has
access to lots of Unicode tables, and in recent JVMs uses native code
to quickly access them) and then filtering that output by the rules in
the XML spec.   

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 18:10:54 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:17:15 2004
Subject: documenting schemas/DTDs
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F278130@MDYNYCMSX1>

>Even a schema spec that allowed very rich documentation in each
>declaration would be at best the equivalent of JavaDoc, and that's not
>good enough.  

Not good enough, but a big positive step nevertheless. Javadoc may not do
that much, but who uses a new Java package without ever looking at the
javadoc-generated documentation?

When I write quick and dirty Java code for my own use, I don't bother with
the javadoc @ fields. When I write code for regular use or for others to
see, I feel guilty if I don't fill in those blanks. It's a long way from
literate programming, but it's better than nothing. While simple dedicated
element types in XSDL would not address the basic problems discussed in this
thread, they too would be better than nothing. 

I understand the benefits of disallowing comments inside of attribute
declarations in the transition from SGML to XML, but I really miss the
ability to put a short comment right next to each attribute so that others
looking at the DTD didn't have to wonder whether an explanation of the
attribute list was before the whole list, after the whole list, or omitted.
What made this useful was not the location of the comment but the explicit
relationship that didn't leave the human reader (or automated process)
wondering where to look for a description of a particular attribute.

Years ago, Earl Hood (with dtd2html) and Microstar (with the read-only
version of Near and Far) provided people with free tools that made it easier
to more quickly understand the information stored in a multi-page DTD. These
tools did a lot just by examining the parent/child/sibling relationships
encoded in DTDs, and they could have done more if they knew where to look
for explicit information about each declaration. Come to think of it, they
both provided their own hacks for storing this information; it would be
great if such programs had a standard place to look and didn't have to
resort to hacks. 

Of course, a properly documented system needs more than this, but more would
be a lot harder, and this much would be very useful. 

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii

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



From barton.stanley at innovision.com  Thu Nov 18 18:22:19 1999
From: barton.stanley at innovision.com (Barton Stanley)
Date: Mon Jun  7 17:17:15 2004
Subject: External Parameter Entities for Reuse?
Message-ID: <4.1.19991118115155.00b196d0@mail>

Greetings!

There has been some discussion on this list recently about people's experience with external parsed general entities.  It sounds to me as though there is general agreement that external parsed general entities should not be employed as a data/object reuse mechanism.

In a somewhat similar vein, I am interested in people's experience with employing external parameter entities as a declaration reuse mechanism.  In other words, is it advisable to use a common set of declarations (i.e. a single, physical entity) across multiple document type definitions?  Why or why not?

Thanks,

Barton Stanley

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



From Rajiv.Mordani at eng.sun.com  Thu Nov 18 18:36:11 1999
From: Rajiv.Mordani at eng.sun.com (Rajiv Mordani [CONTRACTOR])
Date: Mon Jun  7 17:17:15 2004
Subject: Can't subclass ElementNode 
Message-ID: <199911181835.KAA20750@taller.eng.sun.com>

Thid is a bug in the compiler and has been notified to the respective people and 
will be fixed. In the meantime try not to recompile the package. Also try to use 
the Sun jdk 1.2.1 and see if it works cos that seems to work for some of the 
people.

- Rajiv

>Date: Wed, 17 Nov 1999 23:07:46 -0400
>From: Azly NACRO <azly@dsuper.net>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: xml-dev@ic.ac.uk
>Subject: Can't subclass ElementNode 
>Content-Transfer-Encoding: 7bit
>
>Hi,
>
>I've got a java.lang.IllegalAccessError when trying to subclass
>"ElementNode".
>
>java.lang.IllegalAccessError: try to access class
>com/sun/xml/tree/ParentNode from class CapabilityElement
>	at CapabilityElement.appendChild(CapabilityElement.java:88)
>	at
>com.sun.xml.tree.XmlDocumentBuilder.startElement(XmlDocumentBuilder.java:485)
>	at com.sun.xml.parser.Parser.maybeElement(Parser.java:1390)
>	at com.sun.xml.parser.Parser.content(Parser.java:1498)
>	at com.sun.xml.parser.Parser.maybeElement(Parser.java:1399)
>	at com.sun.xml.parser.Parser.parseInternal(Parser.java:491)
>	at com.sun.xml.parser.Parser.parse(Parser.java:308)
>	at XmlCapabilityAccessor.<init>(XmlCapabilityAccessor.java:55)
>	at Test.main(Test.java, Compiled Code)
>
>
>I'm working with jbuilder3 using jdk1.2.
>	java version "1.2"	
>	Classic VM (build JDK-1.2-V, native threads)
>
>I've recompile the sun xml package but I still have the same error.
>
>Any ideas what I can do about this? It would be very inconvenient not to
>be able to subclass ElementNode.
>
>Azly NACRO
>azly@dsuper.net
>UQAM (Montreal)
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 
981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gkholman at CraneSoftwrights.com  Thu Nov 18 19:28:43 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:17:15 2004
Subject: External Parameter Entities for Reuse?
In-Reply-To: <4.1.19991118115155.00b196d0@mail>
Message-ID: <4.2.0.58.19991118141735.00a556e0@pop1.attglobal.net>

At 99/11/18 12:21 -0600, Barton Stanley wrote:
>In a somewhat similar vein, I am interested in people's experience with 
>employing external parameter entities as a declaration reuse 
>mechanism.  In other words, is it advisable to use a common set of 
>declarations (i.e. a single, physical entity) across multiple document 
>type definitions?

It is in my environments.

>Why or why not?

(1) - it allows me to parameterize the declarations of internal general 
entities by using marked sections in external parameter entities (though 
typically for only one model for parameterization reasons and not different 
models for reuse reasons)

(2) - it allows me to collect internal general entity declarations by topic 
(useful for reuse)

(3) - it allows me to include a "package" of declarations under the purview 
of others (e.g. the OASIS Table Model) ... (also useful for re-use)

I don't think I've put the element and attribute declarations for a given 
document model into more than one physical file when I'm responsible for 
the entire DTD, but if it were *really* big I would either do so or 
question why my model was so large.

........... Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-02-0
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


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



From vlashua at RSGsystems.com  Thu Nov 18 19:34:54 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:17:15 2004
Subject: The size of the processor is not the issue
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9D10@MAILPROD>

Think about how hard it was to hand crank a car engine to start it.
Vane


-----Original Message-----
From: Sean Mc Grath [mailto:digitome@iol.ie]
Sent: Thursday, November 18, 1999 4:54 AM
To: xml-dev@ic.ac.uk
Subject: SML: The size of the processor is not the issue


Guys,

There is a lot of talk about how trivial it is to add support
for syntactic feature X to an XML processor and how the gains
of removing it in a putative SML are just not worth it.

I believe this is missing the point.

Imagine a world swimming in XML. *Everything* from Spreadsheet
file formats to HTML will be well formed XML.

It follows that a lot of XML processing will revolve around
transforming XML from one form to another.

It is in this space, transforming XML to XML, that the cost
of all XML 1.0 features are paid. Take the most trivial XML
to XML transformation -- the null transformation. Think about
how hard it is do this for arbirtary XML 1.0 documents.

regards,



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From vlashua at RSGsystems.com  Thu Nov 18 20:01:19 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:17:15 2004
Subject: External Parameter Entities for Reuse?
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9D11@MAILPROD>

See TEI. http://www.uic.edu/orgs/tei

Like classes.

Vane
-----Original Message-----
From: Barton Stanley [mailto:barton.stanley@innovision.com]
Sent: Thursday, November 18, 1999 1:21 PM
To: XML Dev
Subject: External Parameter Entities for Reuse?


Greetings!

There has been some discussion on this list recently about people's
experience with external parsed general entities.  It sounds to me as though
there is general agreement that external parsed general entities should not
be employed as a data/object reuse mechanism.

In a somewhat similar vein, I am interested in people's experience with
employing external parameter entities as a declaration reuse mechanism.  In
other words, is it advisable to use a common set of declarations (i.e. a
single, physical entity) across multiple document type definitions?  Why or
why not?

Thanks,

Barton Stanley

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 20:12:27 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:15 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
Message-ID: <3.0.32.19991118121241.014e4ec0@pop.intergate.ca>

At 09:57 AM 11/18/99 -0800, David Brownell wrote:
>The technique I used in Sun's parser may be good for many folk to steal.
>It involves using the standard Character.getType() method (which has
>access to lots of Unicode tables, and in recent JVMs uses native code
>to quickly access them) and then filtering that output by the rules in
>the XML spec.   

Fine, but the Lark technique *doesn't* require storing any Unicode
tables and thus uses an order of magnitude (probably) less memory; or
am I missing something? -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 20:50:13 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:15 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
References: <3.0.32.19991118121241.014e4ec0@pop.intergate.ca>
Message-ID: <3834661C.A5964954@pacbell.net>

Tim Bray wrote:
> 
> At 09:57 AM 11/18/99 -0800, David Brownell wrote:
> >The technique I used in Sun's parser may be good for many folk to steal.
> >It involves using the standard Character.getType() method (which has
> >access to lots of Unicode tables, and in recent JVMs uses native code
> >to quickly access them) and then filtering that output by the rules in
> >the XML spec.
> 
> Fine, but the Lark technique *doesn't* require storing any Unicode
> tables and thus uses an order of magnitude (probably) less memory; or
> am I missing something? -T.

If you're using Java, there's no incremental cost to using the
tables that already exist -- that's already been paid, whether
you use Lark or not.  That "filtering" stuff doesn't take very
much code at all.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From vlashua at RSGsystems.com  Thu Nov 18 20:58:44 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:17:15 2004
Subject: Do SGML and XML co-exist?
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9D13@MAILPROD>

There are probably those who follow the (sort of XML sort of HTML sort of
CSS) Open E-Book initiative who hear an echo. "It has to be simple."

Once it's a standard, it's simple.

Vane

-----Original Message-----
From: David Megginson [mailto:david@megginson.com]
Sent: Wednesday, November 17, 1999 9:32 PM
To: xml-dev@ic.ac.uk
Subject: Re: Do SGML and XML co-exist?


Len Bullard writes:

 > I sat with the Netscape product manager and had a long discussion
 > in Monterey.  Netscape was late to the party.  Sun found something
 > for Java to do and Oracle joined the party once the W3C pushed
 > hard.  No, in the beginning, David, it was just us chickens and
 > Little Blue.  MS was the smartest bunch in the pack.  Do they do
 > unscrupulous things?  I don't know, but when it comes to
 > recognizing an opportunity and working it, no one is better.  Give
 > 'em credit for knowing how to work the room.

Yes, and admittedly Len knows much more about the early history than I
do, since I wasn't in on those meetings.

I think that we're making different points, though -- my point is that
in the crucial few months immediately *after* XML 1.0 went to REC,
when it had a flash of media attention and had to either gain quick
acceptance or join the very large scrapheap of politely-ignored specs,
XML had or acquired the backing of Sun, IBM, Oracle, and even Netscape
as well as MS.  If XML had gone to REC with only MS and its hangers-on
backing it, it would probably have failed or at least spluttered a
lot.

To Microsoft's credit, they were in the game early (I know that it
took a long time for Sun to really notice XML, even though Jon was
chairing the committee), but that doesn't matter as much to the
outside world, as long as everyone's there at the end.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 21:19:25 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:15 2004
Subject: RDF-Schema (was Re: Why validate?)
In-Reply-To: <38344A41.4E3F9ABC@aifb.uni-karlsruhe.de>
References: <Pine.GSO.3.96.991118111535.13911K-100000@grind>
	<38344A41.4E3F9ABC@aifb.uni-karlsruhe.de>
Message-ID: <14388.27903.886761.167736@localhost.localdomain>

Michael Erdmann writes:

 > In Robins mail about the semantic level of XML as well as what
 > David and Tim write about the inadequacy of DTD to represent
 > meaning, I missed any references to RDF/RDF-Schema (BTW a REC and a
 > PR of W3C), that ---as I understand--- exactly are aimed at
 > providing a formal, ontological, shareable semantics in the world
 > of XML.

Or, you could argue that RDF-Schema simply defines a different kind of
structure -- instead of saying what elements may contain, it says what
classes properties may appear in.  It's the same thing, then, but in a
more specific problem domain (the object world).

That said, I'm a big RDF-Schema fan -- it's quite readable, and I'm
finding some serious interest in both RDF and RDF-Schema out there in
the business world.  I'd very much like to see RDF-Schema go to REC,
even though it's missing some things I think I need.

 > Or do I got something completely wrong. 
 > 
 > Or is XML-DEV not the right place to argue in favor of RDF/RDFS?

This is the best place.  There's also an rdf-dev list, but nobody
posts to it.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clovett at microsoft.com  Thu Nov 18 21:40:33 1999
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:17:16 2004
Subject: Clarification on "Burnt by MSXML.DLL"
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C155E631A@RED-MSG-56>

Thanks for clarifying.  We have been hearing loud and clear that people want
a version of MSXML.DLL that does not depend on any IE4 stuff.  MSXML depends
on IE4 because it uses IE's cool multilanguage support (MLANG) and
networking components (WININET, URLMON).  
 
 -----Original Message-----
From: Ben Berck [mailto:BBerck@ESPS.com]
Sent: Thursday, November 18, 1999 6:23 AM
To: 'xml-dev@ic.ac.uk'
Subject: Clarification on "Burnt by MSXML.DLL"



In a previous message, I wrote: 
>>We have been burnt with relying on MSXML.DLL. 

To clarify, the "Pre-DOM" C++ XML Parser seems to work fine.  

However, this requires that our clients have a particular version of IE
installed on their machines.  My company's tech support staff are constantly
getting calls about why something doesn't work.  Their problem is they don't
have an MSXML.DLL on their system!

The answer is: 
"You have to have IE4, SP1 installed."  This seems to upset a lot of our
corporate clients, who have chosen Netscape as their browser, and they don't
want to have anybody installing newer versions of IE.

Hence, "burnt." 


SIDE NOTE: 
In another project, I'm now using the IE5 DOM and have found it very easy to
use, especially with the VC++ 6.0 #import feature of the DLL. My only
complaint is that the error messages returned are almost always E_FAIL.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991118/e2a7e1aa/attachment.htm
From rja at arpsolutions.demon.co.uk  Thu Nov 18 22:14:27 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:17:16 2004
Subject: Clarification on "Burnt by MSXML.DLL"
References: <2F2DC5CE035DD1118C8E00805FFE354C155E631A@RED-MSG-56>
Message-ID: <018901bf3212$13e30b30$4a5eedc1@arp01>

Clarification on "Burnt by MSXML.DLL">Thanks for clarifying.  We have been hearing loud and clear that people want a version of MSXML.DLL that does not depend on any IE4 stuff.  MSXML >depends on IE4 because it uses IE's cool multilanguage support (MLANG) and networking components (WININET, URLMON).  

If you dont want any IE4 stuff but you want the similar interfaces then ActiveDOM ( VCXML ) is probably your answer for now: 

http://www.vivid-creations.com/dom/index.htm

----- Original Message ----- 
  From: Chris Lovett 
  To: 'Ben Berck' ; 'xml-dev@ic.ac.uk' 
  Sent: Thursday, November 18, 1999 6:49 PM
  Subject: RE: Clarification on "Burnt by MSXML.DLL"


  Thanks for clarifying.  We have been hearing loud and clear that people want a version of MSXML.DLL that does not depend on any IE4 stuff.  MSXML depends on IE4 because it uses IE's cool multilanguage support (MLANG) and networking components (WININET, URLMON).  
   
   -----Original Message-----
  From: Ben Berck [mailto:BBerck@ESPS.com]
  Sent: Thursday, November 18, 1999 6:23 AM
  To: 'xml-dev@ic.ac.uk'
  Subject: Clarification on "Burnt by MSXML.DLL"


    In a previous message, I wrote: 
    >>We have been burnt with relying on MSXML.DLL. 

    To clarify, the "Pre-DOM" C++ XML Parser seems to work fine.  

    However, this requires that our clients have a particular version of IE installed on their machines.  My company's tech support staff are constantly getting calls about why something doesn't work.  Their problem is they don't have an MSXML.DLL on their system!

    The answer is: 
    "You have to have IE4, SP1 installed."  This seems to upset a lot of our corporate clients, who have chosen Netscape as their browser, and they don't want to have anybody installing newer versions of IE.

    Hence, "burnt." 



    SIDE NOTE: 
    In another project, I'm now using the IE5 DOM and have found it very easy to use, especially with the VC++ 6.0 #import feature of the DLL. My only complaint is that the error messages returned are almost always E_FAIL.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991118/6f33a751/attachment.htm
From Daniel.Brickley at bristol.ac.uk  Thu Nov 18 22:25:43 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun  7 17:17:16 2004
Subject: RDF-Schema (was Re: Why validate?)
In-Reply-To: <14388.27903.886761.167736@localhost.localdomain>
Message-ID: <Pine.GHP.4.02A.9911182152060.24464-100000@mail.ilrt.bris.ac.uk>

On Thu, 18 Nov 1999, David Megginson wrote:

> Michael Erdmann writes:
>  > In Robins mail about the semantic level of XML as well as what
>  > David and Tim write about the inadequacy of DTD to represent
>  > meaning, I missed any references to RDF/RDF-Schema (BTW a REC and a
>  > PR of W3C), that ---as I understand--- exactly are aimed at
>  > providing a formal, ontological, shareable semantics in the world
>  > of XML.
> 
> Or, you could argue that RDF-Schema simply defines a different kind of
> structure -- instead of saying what elements may contain, it says what
> classes properties may appear in.  It's the same thing, then, but in a
> more specific problem domain (the object world).

I've been thinking a lot lately about how to characterise what RDF
Schema tries to do. I think it falls into two parts: firstly, we say
'use RDF to describe itself', and secondly, we provide some simple RDF
vocabulary constructs to begin this task. So, the second aspect of RDF
Schema is (for a different domain) broadly analagous to the
elements/attributes level of XML DTDs. But the first aspect of RDF
Schema, ie. building something more intrinsically self-descriptive,
feels different to what we have in DTDs.

That's longwinded; I'll try again. The current facilities actually
provided in RDF Schema are roughly as expressive as DTDs, but the
information model behind what RDF Schema 1.0 gives us is
more easily extended. For example, much richer constraints for RDF
schemata should be pretty easy to define once we have an RDF query
language useable for expressing them.

> That said, I'm a big RDF-Schema fan -- it's quite readable, and I'm
> finding some serious interest in both RDF and RDF-Schema out there in
> the business world.  I'd very much like to see RDF-Schema go to REC,
> even though it's missing some things I think I need.

Do you think these can be layered on afterwards in subsequent
specifications? If so, that's the best place for them.

>  > Or do I got something completely wrong. 
>  > 
>  > Or is XML-DEV not the right place to argue in favor of RDF/RDFS?
> 
> This is the best place.  There's also an rdf-dev list, but nobody
> posts to it.

Yeah but...

RDF-DEV / RDF Interest Group mailing list update time...

As RDF-DEV listowner I decided to merge that list in with the new
RDF Interest Group list we've just set up. The W3C RDF Interest Group
pages (including archives and list signup details) are at:

	http://www.w3.org/RDF/Interest/

Now the RDF-DEV / RDF IG list convergence is mostly behind us it seems a
good time to circulate a call for partipation in the RDF Interest Group.
(For a while I dithered about shutting down RDF-DEV but was definitely
the right thing to do; this was why it took until now to get the RDF IG
details more broadly circulated).

The RDF Interest Group charter is at http://www.w3.org/RDF/IGcharter

We've had 100 posts in 14 days on RDF Interest Group list[1]; that's
roughly what we had in 3+ months on RDF-DEV.

More list-members always welcome. To subscribe to the RDF
Interest Group mailing list, send a message: 

	To: www-rdf-interest-request@w3.org
	Subject: subscribe


Recent discussion has included simplification of RDF syntax, storing
RDF models in relational databases, cambridge communique, proposals for
RDF APIs, and various other thinkings-out-loud...

Dan



[1] http://lists.w3.org/Archives/Public/www-rdf-interest/


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



From martind at netfolder.com  Thu Nov 18 22:59:34 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:16 2004
Subject: About templates
Message-ID: <NBBBJPGDLPIHJGEHAKBAOEPCEGAA.martind@netfolder.com>

Hi,

After some months of silence, several hundred miles with my bike in China,
writing about XML for Wrox, I am now back to work on new things. Recently, I
made an interesting discovery. I tried to simulate a world full of XML
browsers and what would be the implications of such world.

a) The whole notion of XML server may change. Different XML document
providers or should I say XML fragment providers will emerge. Among them: 1)
relational data base accessible with URLs, HTTP and datasets returned as XML
documents. Directory services (same scenario), e-commerce services, etc...
In fact, in the following month we'll see a plethora of new XML servers
appearing on the market. We already have technological previews from Oracle
and Microsoft's for their respective RDBMS.

b) The notion of XML fragment is becoming more and more important. A request
to an XML server may not necessarily mean that the result should be a
complete XML document but more a fragment to be included in a template.

c) The notion of an XML template will become more important than ever. The
template provides a framework for document assembly. In this template we
specify which fragment we want. For example, a template may request XML
fragments from a LDAP server and a fragment from a relational database. The
actual notion of template we currently have (through style sheets) is that
the result tree source is an XML document. This may not be the case for most
e-commerce applications where fragments have to come from other sources. In
an XML template, like it is now for an XSL templates, some elements are
replaced by XML fragment coming from XML servers (like for instance a
relational DB).

d) Finally the document assembled from fragments is sent to the browser and
rendered with a style sheet.

So, what we have now to think more of is:

1) XML document fragments
2) XML templates. The format may be the same as the XSL simplified format -
or XSLT could be extended to support document assembly from XML servers.
This implies that new elements have to be defined like for example database
SQL request. Actually, Microsoft uses their own sql name space (i.e.
<sql:query> ) and Oracle their own implicit one (i.e. <QUERY> ). Idem for
directory services DSML lead by a NH startup. Do we extend XSLT to include
these new constructs? So, XSLT would no longer be for XS Transformations but
more for XS Templates :-)
3) The returned elements in the case of RDB and directory services would
benefit greatly to follow the RDF format. IN this case RDF wouldn't be
solely limited to meta data (yes I agree with you on this David :-)

Suggestion:
for a RDB row we would have:
<rdf:description about="urn:<DB>:<table>:<key>">
....fields here....
</rdf:description>

for a directory service:
<rdf:description about="ldap://ldap.itd.umich.edu/c=us">
...ldap fields here....
</rdf:description>

the problem though, could be with rendition if all fragment elements are rdf
elements. This could be prevented by the fragment type or the enclosing
element. For instance a RDB may return elements of type <database> and
directory services of type <directoryservice> then a style sheet can be set
to the proper context.

Like Paul Valery said at the beginning of the century said:
Act like a man of reflection and think like a man of action.

I am writing a document about these issues on a more elaborate format and
will submit it to you for comments. Until then, do others share the same
interest for a common solution for a piece of the semantic net?

PS: about SML my answer is why not? let's pursue this and see what can come
out of this. Let's see the process as a kind of stepwise refinement from the
complex to the simple. This is a journey ususally not done in a single step
since we have to deal with the inertia of history :-). And after all, a
different point of view may worth a thousand point of IQ, so let's try and
see...
Duane, during my trip, this was the first time in my life that I saw a bike
trafic jam. You know what, it is as worse as a car trafic jam :-)

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 18 23:16:09 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:16 2004
Subject: RDF-Schema (was Re: Why validate?)
In-Reply-To: Dan Brickley's message of "Thu, 18 Nov 1999 22:25:17 +0000 (GMT)"
References: <Pine.GHP.4.02A.9911182152060.24464-100000@mail.ilrt.bris.ac.uk>
Message-ID: <m37ljf5r4p.fsf@localhost.localdomain>

Dan Brickley <Daniel.Brickley@bristol.ac.uk> writes:

> That's longwinded; I'll try again. The current facilities actually
> provided in RDF Schema are roughly as expressive as DTDs, but the
> information model behind what RDF Schema 1.0 gives us is
> more easily extended. For example, much richer constraints for RDF
> schemata should be pretty easy to define once we have an RDF query
> language useable for expressing them.

I agree -- RDF-Schema does the same kind of thing in its domain as
DTDs or XML Schemas do in theirs, but it takes a different approach:
DTDs and other schema proposals, as well as UML, are top-down, while
RDF-Schema is bottom-up.  This is a difference in its approach,
though, not in its nature.

My very favourite thing about the RDF model is the fact that
properties are first class things, independent of the classes of the
objects to which they're attached.

> > That said, I'm a big RDF-Schema fan -- it's quite readable, and I'm
> > finding some serious interest in both RDF and RDF-Schema out there in
> > the business world.  I'd very much like to see RDF-Schema go to REC,
> > even though it's missing some things I think I need.
> 
> Do you think these can be layered on afterwards in subsequent
> specifications? If so, that's the best place for them.

Absolutely correct.  Put what you have now out as soon as you can, and
then collect feedback for v.2 -- I promise to send some detailed
comments *after* RDF-Schema v.1 goes to REC.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rja at arpsolutions.demon.co.uk  Thu Nov 18 23:39:31 1999
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:17:16 2004
Subject: Are you sure the XML decl shouldnt be a PI ? :)
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com> <008701bf2e42$92747c50$4a5eedc1@arp01> <m34sepfeai.fsf_-_@localhost.localdomain> <006101bf2ecd$8b434c00$4a5eedc1@arp01> <m39040pujk.fsf@localhost.localdomain>
Message-ID: <003901bf321d$f8358280$4a5eedc1@arp01>

BTW, I noticed that the XML recs in XML have these two entities:

<!ENTITY xmlpio "'&lt;?xml'">
<!ENTITY pic    "'?>'">

XML Pi Open, XML Pi Close maybe ? 

: )


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 00:29:51 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:17:16 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
References: <3.0.32.19991117162449.01abfa10@pop.intergate.ca> <38343DFF.99390CD2@pacbell.net>
Message-ID: <383499BA.F3941A65@infinet.com>

David Brownell wrote:

> Tim Bray wrote:
> >
> > The performance is good enough that in Lark, the limiting factor was
> > my lousy input buffering, not the character class checking; and Lark
> > was always in the top half of the performance table. -Tim
>
> I think that's pretty typical.  I've profiled several parsers by now,
> and character class checking hasn't been a major issue ... usually
> one or two percentage points CPU time for testing whether a character
> works in a name (first/rest) or not.
>
> The technique I used in Sun's parser may be good for many folk to steal.
> It involves using the standard Character.getType() method (which has
> access to lots of Unicode tables, and in recent JVMs uses native code
> to quickly access them) and then filtering that output by the rules in
> the XML spec.

That is one way to do it. What I found worked optimally in my case is to pregenerate a bitmap
of all legal name and name start characters, save it to a file, and load it when using the XML
parser into a constant array of integers (integer arrays in Java are faster to access because
comparisons don't require a cast after retrieval). It takes up a little bit of extra memory
but I think it is well worth it. Other Java XML parsers I have seen use a similiar approach
except that the store the character bitmap in the class file itself which has the unfortunate
problem of bloating the size of your class file immensely, and slowing down startup time
because the stupid way Java deals with constant arrays of primitive types in classes is that
it generates instructions for initializing each section of the array to the desired value
instead of just having a stream of bytes that are read into the array one by one. I opted to
initialize the array of name and namestart characters from a file because the startup time for
the class was considerable as you needed to loop 128,000 times and test each index against a
isNameChar() function or a isNameStartChar() function or something like that.

I could use this method for testing whitespace as well as well as other characters, but it
hardly seemed worthwhile because all of the whitespace characters can be tested with a
switch/case statement and testing for all of the other special characters do not occur enough
in an XML document to mandate adding another 2048 integers into memory.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 00:45:10 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:16 2004
Subject: Parser compliance
In-Reply-To: <199911181333.IAA07328@hesketh.net>
Message-ID: <002301bf3227$9ffc7920$099918d1@docuverse1>

Simon St.Laurent wrote:
>I think that a large part of the reason book and article writers have
>focused on DTDs is their large (and relatively difficult) place in the
>XML 1.0 specification and the need to explain to people some kind of
>technical-sounding 'how' of creating new vocabularies.

I have long suspected that human brain has very limited ability to
ignore information and there is stress involved in doing so.  Yesterday,
I took the XML 1.0 spec and removed sections upon sections to create
a rough draft of the SML spec.  My goal was to feel the impact of such
simplification.  The result, to me at least, was very startlingly good.

Removal of DTD related sections alone was like taking a huge load off
my mind and the spec flows much smoother to boot.  I think most of us
have underestimated the amount of intellectual stress each piece of
detail places on our mind.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 01:26:10 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:16 2004
Subject: Do SGML and XML co-exist?
References: <383233D8.46BC@hiwaay.net> <m3aeod6lug.fsf@localhost.localdomain> <38335F04.1303@hiwaay.net> <38336763.506679C7@prescod.net>
Message-ID: <38349B4B.76EC@hiwaay.net>

Paul Prescod wrote:

Let me say, I never invented anything that has to do with SGML and 
markup systems.  I am and was a user of such systems, just a musician 
who had this strange notion that timing and synchronization were key 
to the problems of enterprise engineering.  That's all.  I am  
an older user than most of you and because of that, I was a minor 
observer of some of the history and people who did invent markup.  It
was 
a privilege and an honor.  It was at times, thrilling.
 
> I don't believe that. There was a requirement for an e-commerce and data
> interchange meta-language. We were there first. 

Interestingly, it had been brought up before XML was gleam.  Every time
someone 
suggested to the EDI committees that markup was preferable, it was 
dimissed as an irrelevant text format.  When I was at the PDES meetings 
when SGML was first considered, it was only as a string alternative 
to the somewhat byzantine document model they were building.  No, Paul, 
two things made the EDI folks take it seriously:  MS was backing it 
and it was going On The Web.  If I can find Rita Knox, we can probably 
still get an authoritative, deeply technical, and completely irrelevant 
analysis of why markup is a bad idea.  If Betty Harvey remembers, at one 
point, HTML was all that mattered.  If I am honest, I thought Hytime 
would change the world.

We all have those moments.

> The client side (if it
> ever materializes) will be gravy. Microsoft probably accelerated the
> process but there was a desperate market need for a faster way to
> describe data interchange languages than BNF and SGML really should have
> been there several years ago but for the stigma and the DTD dependency
> issue.

The stigma is the interesting issue.  We already knew how to work with 
well-formed files and without DTDs.  We struggled against the SGMLWay, 
the consultancies, and the fact that before HTML blew away all other 
competitors, we could not get a hearing.  Why?  Politics and money.  

I had the good fortune in Orlando to watch Dr. Goldfarb take on Larry 
Welch from NIST.  It was incredible to see this balding bearded 
Jewish lawyer with cowboy boots and a string tie taking notes 
on that long yellow legal pad, drop his glasses to the end of his 
nose, then devastate Welch.  Welch hateed SGML.  He used his
considerable 
girth and position to fight it at every turn.  That was what SGML was 
up against:  committees, power brokers in Washington and elsewhere,
people 
with petty empires and overarching ambitions.   

Most of you on this list probably don't have the real picture of 
what you owe Goldfarb.  Considerably more than a beer, 
but if you meet him, consider yourself lucky and buy him one if Linda 
isn't looking.  He built this language, folks.  Some of you are 
getting credit and pocket change, but he made this happen.  Not Jon, 
not Tim, not TimBL.  I respect those guys, but Goldfarb paid for this
party.  
Respect is owed; respect is due.

So why did some of us go with the SGML On The Web project:

1.  It was the right thing to do.  HTML is an SGML application.  I had 
to defend it in DC against every comer.  Even when I knew there were 
better designs, it was evolving fast and at a certain point, it met 
the requirements, so Selah.  Shake hands and move on.  I stood in front 
of the assembled IETM cognoscenti of Lockheed Martin in Orlando and told 
them, yes, we spent a lot of money, we've done a lot of good work. 
Consider 
it training.  Now, get with the program.  The Web wins.  It hurt, but 
it was the right thing to do.  As a professional, one will have those 
moments.

2.  We needed a means to focus the SGML community.  The long time
waiting 
for DSSSL to be completed (the real tent pole), the suffering with FOSI 
based systems so complicated we could never get them in high producion, 
the mysterious, inscrutable and ultimately overbuilt HyTime standard,
all of 
this had gone on too long.  Without the web and the money, there was no
way 
the excellent conceptual foundations of SGML would have survived.

3.  It wasn't money, at least, not for me.  Haven't made a dime on it.  
Probably won't.  I've invested a lot of time in VRML and the fruits 
of that are just emerging not as money, but in that next year, there 
will be a markup version of animtated 3D. I helped make that happen.
Why?  It is the right thing to do.  Wall-to-wall markup systems have 
the potential to make the Total Cost of Ownership (TCO) of complex 
information come down.  Real time 3D is a very key piece and we have 
known that since at least the eighties.  To happen we had to get 
off expensive platforms.  Today we have 50 cent memory and two 
dollar processors.  Time for Phase II.

It takes a long time to do some kinds of work.  You will meet a lot of 
people, eat a lot of bad food, and stay in some nasty rooms.  You will 
have a lot of laughs,  some mindbending arguments, shed a few 
tears, and only win some of the games.  You will give up some things 
you hold dear, risk friends, alienate allies, even walk away when 
you are the impediment, not the solution.  Ask yourself why and be
honest 
about it.  Money only goes so far. 

It ls what it has always been:  we have to protect information, 
as Charles said, "from folks like us".   Why?  The humans matter 
more than the machines.  They need information, and for that,
information 
must be free of implementation.  It isn't content vs presentation.  
That is an old red herring.  It is content independent of
implementation. 
The reason some us understand DTDs.   SGML and XML 
aren't inevitabilities.  They never were.  They are there because 
two and now three generations of information pros and users fought 
for them.  There Ain't No Justice Unless You Make It So.  We aren't 
martyrs;  we are pros.  We take pride in it.  It is, as Lawrence 
told the Sheik, "our pleasure" to do it.  We do it for people. 

But as Megginson notes, without the money, it isn't comfortable and 
with the money, it is a lot more exciting if a lot more crowded. I just 
won't sit here and let history be rewritten by newbies and those 
with a platinum axe to grind.  I accept XML.  How many of you on the 
list accept that XML is SGML, and because of it, has a proud and well 
respected heritage made by people whose names are fading faster than 
the sun over the Pacific?  Respect is owed; respect is due.
 
> Admittedly, had Microsoft come out with an XML *competitor*, XML might
> have been in trouble. But if they sat on their hands, we would still
> need to solve the Internet e-commerce issues with or without them and I
> don't see any other proposals for data interchange meta- and schema-
> languages.

Common LISP comes to mind.  S-expressions, as Dan Connoly told me, are 
the highest form.  Why not LISP?  Well, because HTML wasn't written 
in LISP.  As the twig is bent, so grows the tree.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 01:26:12 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:16 2004
Subject: documenting schemas/DTDs
References: <8D96EDA0AC04D31197B400A0C96C1480811034@ossex1.ossinc.net> <38337644.5A0EC416@isogen.com> <m3n1sc59sn.fsf@localhost.localdomain>
Message-ID: <38349E00.760D@hiwaay.net>

David Megginson wrote:
> 
> > If you are are creating DTD-syntax DTDs, the syntax of DTDs is simply
> > not up to the task of maintaining and managing documentation of any
> > useful sophistication.
> 
> I agree very strongly with Eliot, perhaps because we both have a lot
> of experience in creating (rather than just processing) user
> documentation.
> 
> Even a schema spec that allowed very rich documentation in each
> declaration would be at best the equivalent of JavaDoc, and that's not
> good enough.  The problem (and this is a classic in tech writing) is
> that the optimal way to arrange information for a human reader is
> rarely the optimal way to arrange information for technical
> implementation, and vice versa.

I also agree with Eliot.  On the other hand, when handed thousands 
of pages of SGML for the C-130 to convert, it took both the comments 
and the structural validation capabilities to make the translation, 
and that was SGML to SGML.  

It isn't that DTDs are the end all tool, they are just a very useful 
one and common experience bears that out particularly where the people 
doing the work aren't computer scientists or consultants.  The joy of 
using it is the EASE of using it.

Without the comments, it was a best guess affair; without the 
declarations, it was hopeless.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 01:26:17 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:16 2004
Subject: History
References: <3.0.32.19991117204736.01446c00@pop.intergate.ca>
Message-ID: <3834A52A.477E@hiwaay.net>

Tim Bray wrote:
> 
> So Len says that it only went over the top because Microsoft liked it.  Len
> is mostly wrong, but he's used to me saying that and sometimes I'm wrong
> when I do.

I am used to that.  Reasonable minds can disagree.  I think that without 
Microsoft's support, getting the XML WG to the finish line would have 
been more than difficult.  It wouldn't have happened.  Not then anyway.
 
> For the record.  By the end of 1995, anyone with half a brain could see that
> HTML was just not up to some of the jobs that people wanted to get done on
> the Web.  

Yes.  OTOH, the GenCode folks knew before then.  It was hard to get
people 
to realize that elegance and success don't always go to the ball
together.  
Some simple ideas go like a grassfire because they give that girl on TV 
who can't handle her VCR something she can handle. When Mikey likes it, 
he really likes it, but if a star sells it, it really sells.

> In parallel, some of us had been shouting at the SGML crowd from
> inside for years that SGML needed radical simplification.  I can remember
> like yesterday at the big SGML conference in 93 or 92 or so, standing around
> with Steve DeRose and Jean Paoli and Erik Naggum (most XMLers won't remember
> him) agreeing that we ought to do this.  But we didn't, then.

Yes.  In 1992, I was demonstrating a radical simplification of SGML in 
the IADS application which relied on.... stylesheets and a well-formed 
file all processed on a 386.    I know where de Rose was;  he was
selling 
Dynabook for 50k a pop.  We were giving away IADS.  You were selling 
relational databases then, right?  Can't remember.  The first time 
we met was in the hallway in Vancouver.  I was listening; you were 
angry.  You were right.

Sure, SGML needed simplifying.  Remember, in those days, 
the hypertext advocates were referred to as "the left wing lunatic 
fringe of SGML" by the 28001 committees.  It took a few more 
years of starvation for pony tails to come into vogue.

As for Erik?  He was holding up comp-text-sgml and fighting with 
anyone who would spar with him.  I do miss Erik.  Excellent wits.
 
> I got invited to join the original XML committee because at SGML/Europe
> in 1996 in Munich, I gave a closing keynote inviting the crowd to dispense
> with 80% of it.

So why do we have 80% of it there and more being asked for? 

> It is to Jon Bosak's immense credit that he (like many of us) not only
> saw the need for simplification but (unlike anyone else) went and hounded
> the W3C until it became less trouble for them to give him his committee than
> to keep on saying SGML was irrelevant.

Yep.  Jon mastered DSSSL.  I have to give him credit.  I gave up on
that.  
Too hard.
 
> Speaking as one of Jon's nominees I am naturally of the opinion that he
> couldn't have picked a better group, but I kinda think that any group of
> SGML veterans, some of whom had operated large web sites, would have done
> about as well.

Given the SIG and the WG in total, that was pretty much every SGMLer on 
the planet with a modem.  I would have more respect for the founders had 
they been more honest about what they had in mind.  On the other hand, 
with enough of the SGMLers in the crowd, it didn't get too far off
track.  
It did manage to pull ISO and the W3C closer and that was worth all the 
hassle.  In the years to come, a healthier and more productive
relationship 
between the inner and outer loops will benefit everyone.
 
> And then... First off, Microsoft deserves a lot of credit for Getting It way
> before many other allegedly smart industry leaders.  But there were a bunch
> of reasons, some of them accidents of history, why it went over the top.
> One of them was, people looked at it seriously because Microsoft was onside.
> They soon noticed that unlike a lot of other things Microsoft liked, it was
> unlikely to be something that Microsoft could control.

That was the beauty of it, and the one thing to be said in the defense
of 
MS.  They understood the price of supporting it, but they saw the
enormous 
advantage of getting as far as they could as fast as they 
could.  We can debate some what ifs, but we agree, they got out front 
first.
 
> Any simple explanation of XML's success is simply wrong.  Life, and the
> Web biz, are complicated.

No, there are just lots of points of views.  We express them here and 
let the press figure out a shorter more acceptable version.  Life and 
is simple:  duty, wealth, pleasure.  The web biz: paste .com on the 
end of the company name, then get venture capital and an IPO.  Seems 
to be working for Doonesbury.
 
> It was astounding; Jon and I and some of the others made a concentrated
> marketing effort starting at the end of 1996 and went shouting off in all
> directions about XML.  It was like hurling your entire weight against a
> locked door that turns out not to be there.  The world, more or less, said
> "yeah, OK".

Which is another way of saying, good timing.  Emergence works like
that.  
Like surfing, you only want to swim out as far as you can swim back, and 
always be in the power curve before you stand up.  Enjoy the ride.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 02:16:19 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:16 2004
Subject: About templates
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAOEPCEGAA.martind@netfolder.com>
Message-ID: <000201bf3234$56634de0$099918d1@docuverse1>

Didier PH Martin wrote after a long absence:
>PS: about SML my answer is why not? let's pursue this and see 
>what can come out of this. Let's see the process as a kind of
>stepwise refinement from the complex to the simple. This is a
>journey ususally not done in a single step since we have to
>deal with the inertia of history :-). And after all, a
>different point of view may worth a thousand point of IQ, so 
>let's try and see...

This is precisely my attitude toward SML.  Lets just see whats
over the next hill.  If there is a tiger in the hill, I won't
be home for dinner.  If not, I won't be home for dinner. <g>

You brought up an important point which has been rattling in
my brain (it could be a loose bolt) which is: XML fragments
are important.  Your template idea is also important.  What is
missing is the idea of schema fragments which are similar to
XHTML module idea except at a smaller scale, more like molecules
rather than bricks.

Smaller schema fragments can be used to form larger schema
fragments.  A simple schema fragment is a integer data schema
fragment.  Such a schema can be used to to create a domain
specific schema fragment like ZIP code.

I am now leaning very heavily toward focusing SML on XML fragments
so that SML data (the word 'document' is not in the SML draft spec)
starts with the 'content' production rule of the XML spec.  No
prolog, no misc.  SML data have zero or more elements and can be
entirely text.  Interesting thoughts.  I have yet to see clearly
where this line of thinking will lead to but I am having fun.

May your tire pressure remain constant,

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From harvey at eccnet.eccnet.com  Fri Nov 19 02:44:39 1999
From: harvey at eccnet.eccnet.com (Betty L. Harvey)
Date: Mon Jun  7 17:17:17 2004
Subject: History
In-Reply-To: <3834A52A.477E@hiwaay.net>
Message-ID: <Pine.LNX.4.10.9911182104500.4282-100000@eccnet.eccnet.com>


Sorry - I have to pipe in.  I have missed most of this discussion because
of system upgrades and e-mail being down for 2 1/2 days - so excuse me
if I don't get the context of these last e-mails.

Personally, I give credit to Yuri Rubinsky, President of SoftQuad until
his untimely death, to the birth of XML. I give credit to Tim Berners-Lee
for the insight to recognize that SGML was format for the Web - HTML.  He
could have chosen NROFF, RUNOFF - any of those other system formatting
languages but he chose SGML - Thank you very much.

As Len said, I spent time and a lot of hard knocks with CALS (SGML and EDI
both being part of the CALS standards.  CALS initially represented
Computer Aided Logistics Support, then Continuous Acquisition and
Lifecycle Support (change the meaning of the acronym when it becomes
political incorrect).  Before I worked for the CALS program I was
told that working in CALS was a dead-end to your career.  

When the Web came into existance I was working in CALS within the Navy and
with our local Technology Transfer czar at David Taylor Model Basin.  I
was positive that SGML could not work at a reasonable cost and effort
within a large organization, such as DoD. The Technology Transfer office
funded my way to the second WWW Conference in Chicago (the first in the
U.S.). It is still the best conference I have ever attended.  The
enthusaism was incredible. I can't remember anytime in my career, before
or after, feeling so inspired.

I think I had the privilege of showing Len the WWW for the first time
at David Taylor using Mosaic on a Sun system.  After working with
complex IETM (Interactive Electronic Technical Manual) specifications
and expensive IETM unglamorous browsers the fact that Mosaic was
free, multiple platforms (unheard of until then), had a 'sexy' 
display was exciting.  I tried to talk the Navy into modifying
Mosaic code (it was public domain) to support IETMs.  The climate
wasn't right in 1994 for heresy. Today most IETM projects are
Web based.

Yuri chaired a session called 'SGML on the Web'.  In my mind it
finally clicked!!  I felt so strongly about 'SGML on the Web' i.e.,
XML that I left a safe and long civil servant career to support the
'SGML on the Web' effort.  

It does distress me that now that XML has become popular that the pioneers
are forgotten, especially Yuri.  He was a man who impacted not only the
web but people positively.  He was a real visionary.  I also believe he
would be really pleased about the current XML efforts.

XML is becoming prolific because it is a good technology and people
(computer scientists and marketeers) can understand it.  Even if Microsoft
hadn't embraced it (I am glad they did) it still would have been accepted
because of the other vendors who lined up to support it.  There are
several reasons that SGML didn't become very popular; (1) little vendor
support, (2) too costly, (3) too complex, and (4) personally, I believe
too esoteric.  XML is real!

Enough history - back to technical discussions.  BTW, congratulations
on XSLT and XPath!!!!  This is a major achievement.

In conclusion - thanks Charles, Yuri, TimBL and many others for their
vision!

Betty

On Thu, 18 Nov 1999, Len Bullard wrote:

> Tim Bray wrote:
> > 
> > So Len says that it only went over the top because Microsoft liked it.  Len
> > is mostly wrong, but he's used to me saying that and sometimes I'm wrong
> > when I do.
> 
> I am used to that.  Reasonable minds can disagree.  I think that without 
> Microsoft's support, getting the XML WG to the finish line would have 
> been more than difficult.  It wouldn't have happened.  Not then anyway.
>  
> > For the record.  By the end of 1995, anyone with half a brain could see that
> > HTML was just not up to some of the jobs that people wanted to get done on
> > the Web.  
> 
> Yes.  OTOH, the GenCode folks knew before then.  It was hard to get
> people 
> to realize that elegance and success don't always go to the ball
> together.  
> Some simple ideas go like a grassfire because they give that girl on TV 
> who can't handle her VCR something she can handle. When Mikey likes it, 
> he really likes it, but if a star sells it, it really sells.
> 
> > In parallel, some of us had been shouting at the SGML crowd from
> > inside for years that SGML needed radical simplification.  I can remember
> > like yesterday at the big SGML conference in 93 or 92 or so, standing around
> > with Steve DeRose and Jean Paoli and Erik Naggum (most XMLers won't remember
> > him) agreeing that we ought to do this.  But we didn't, then.
> 
> Yes.  In 1992, I was demonstrating a radical simplification of SGML in 
> the IADS application which relied on.... stylesheets and a well-formed 
> file all processed on a 386.    I know where de Rose was;  he was
> selling 
> Dynabook for 50k a pop.  We were giving away IADS.  You were selling 
> relational databases then, right?  Can't remember.  The first time 
> we met was in the hallway in Vancouver.  I was listening; you were 
> angry.  You were right.
> 
> Sure, SGML needed simplifying.  Remember, in those days, 
> the hypertext advocates were referred to as "the left wing lunatic 
> fringe of SGML" by the 28001 committees.  It took a few more 
> years of starvation for pony tails to come into vogue.
> 
> As for Erik?  He was holding up comp-text-sgml and fighting with 
> anyone who would spar with him.  I do miss Erik.  Excellent wits.
>  
> > I got invited to join the original XML committee because at SGML/Europe
> > in 1996 in Munich, I gave a closing keynote inviting the crowd to dispense
> > with 80% of it.
> 
> So why do we have 80% of it there and more being asked for? 
> 
> > It is to Jon Bosak's immense credit that he (like many of us) not only
> > saw the need for simplification but (unlike anyone else) went and hounded
> > the W3C until it became less trouble for them to give him his committee than
> > to keep on saying SGML was irrelevant.
> 
> Yep.  Jon mastered DSSSL.  I have to give him credit.  I gave up on
> that.  
> Too hard.
>  
> > Speaking as one of Jon's nominees I am naturally of the opinion that he
> > couldn't have picked a better group, but I kinda think that any group of
> > SGML veterans, some of whom had operated large web sites, would have done
> > about as well.
> 
> Given the SIG and the WG in total, that was pretty much every SGMLer on 
> the planet with a modem.  I would have more respect for the founders had 
> they been more honest about what they had in mind.  On the other hand, 
> with enough of the SGMLers in the crowd, it didn't get too far off
> track.  
> It did manage to pull ISO and the W3C closer and that was worth all the 
> hassle.  In the years to come, a healthier and more productive
> relationship 
> between the inner and outer loops will benefit everyone.
>  
> > And then... First off, Microsoft deserves a lot of credit for Getting It way
> > before many other allegedly smart industry leaders.  But there were a bunch
> > of reasons, some of them accidents of history, why it went over the top.
> > One of them was, people looked at it seriously because Microsoft was onside.
> > They soon noticed that unlike a lot of other things Microsoft liked, it was
> > unlikely to be something that Microsoft could control.
> 
> That was the beauty of it, and the one thing to be said in the defense
> of 
> MS.  They understood the price of supporting it, but they saw the
> enormous 
> advantage of getting as far as they could as fast as they 
> could.  We can debate some what ifs, but we agree, they got out front 
> first.
>  
> > Any simple explanation of XML's success is simply wrong.  Life, and the
> > Web biz, are complicated.
> 
> No, there are just lots of points of views.  We express them here and 
> let the press figure out a shorter more acceptable version.  Life and 
> is simple:  duty, wealth, pleasure.  The web biz: paste .com on the 
> end of the company name, then get venture capital and an IPO.  Seems 
> to be working for Doonesbury.
>  
> > It was astounding; Jon and I and some of the others made a concentrated
> > marketing effort starting at the end of 1996 and went shouting off in all
> > directions about XML.  It was like hurling your entire weight against a
> > locked door that turns out not to be there.  The world, more or less, said
> > "yeah, OK".
> 
> Which is another way of saying, good timing.  Emergence works like
> that.  
> Like surfing, you only want to swim out as far as you can swim back, and 
> always be in the power curve before you stand up.  Enjoy the ride.
> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Fri Nov 19 04:22:04 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:17 2004
Subject: Feeler for SML (Simple Markup Language)
In-Reply-To: <00bf01bf2fb0$9e87c230$e5bdb3c7@PTGRESTON>
Message-ID: <000101bf3245$20581940$fad45dc7@ebt.com>

> 1 - I'd like to see an activity not unlike the one that
> defined SAX a couple of years ago collaboratively researching what a
minimal
> subset of XML and/or the DOM  for high-performance and/or small footprint
> processors might look like.

I think there is certainly scope for another API in certain application
domains. We've talked about this before.



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



From gtn at ebt.com  Fri Nov 19 04:22:04 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:17 2004
Subject: Feeling good about SML
In-Reply-To: <3.0.6.32.19991116115426.0092c690@gpo.iol.ie>
Message-ID: <000301bf3245$239d5930$fad45dc7@ebt.com>

> 1) Tie down what the bifurcation areas that cause XML
> interoperability problems and allow people to throw
> the phrase "XML parser" around with wild abandon.
> e.g. external subset processing, external entity references,
> Unicode encoding(s) supported, location information, etc. etc.
> 
> For arguments sake, lets call this the XML Feature Manifest
> (XMF).
> 
> 2) Tie down a syntax -- presumably canonical XML -- to
> store XFM.
> 
> 3) XML parser writers would be encouraged to provide
> an XFM so that humans and programs alike can determine
> what the parser does and does not support.
> 
> 4) XML Document Creators would be encouraged to
> tack an XFM onto their document collections so
> that humans and programs alike can determine
> what XML features the document-set requires.

This seems like an excellent suggestion...  much better than
inventing another language, and besides, the XFM would be
great input into the SML analysis process.

Personally, I cannot see the value of SML... though I 
understand where people are coming from regarding it. 
If people *really* want another format for high-performance
situations, I'm not even convinced that the XML-ish syntax
is ideal. It seems to me that maybe people are trying to
ride on the XML hype...


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



From gtn at ebt.com  Fri Nov 19 04:22:04 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:17 2004
Subject: External Entities A Field Guide (was RE: Feeler for SML (Simple Markup Language))
In-Reply-To: <000d01bf301f$d2c357c0$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <000201bf3245$2265c390$fad45dc7@ebt.com>

> "The *ONLY TIME* external parsed entities are the right thing to do is
> when exactly one actor is working on exactly one doucment and needs to
> partition it into separate files for *their own* convenience. *AT ALL
> OTHER TIMES* external parsed entities are not the right thing to use."
> http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0238.html

I quite strongly disagree with this, as does the practical experience of
many people on this list.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 04:40:07 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:17 2004
Subject: External Entities A Field Guide (was RE: Feeler for SML 
 (SimpleMarkup Language))
References: <000201bf3245$2265c390$fad45dc7@ebt.com>
Message-ID: <3834D497.8559E990@pacbell.net>

Gavin Thomas Nicol wrote:
> 
> > "The *ONLY TIME* external parsed entities are the right thing to do is
> > when exactly one actor is working on exactly one doucment and needs to
> > partition it into separate files for *their own* convenience. *AT ALL
> > OTHER TIMES* external parsed entities are not the right thing to use."
> > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0238.html
> 
> I quite strongly disagree with this, as does the practical experience of
> many people on this list.

Come to think of it ... doesn't the XHTML spec reuse parameter
entities?  Those are "external parsed entities".

In that case it'd be evil to have multiple copies of declarations
for internal entites like "ldquo", "rdquo", "AElig" and so on.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 04:41:34 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:17 2004
Subject: documenting schemas/DTDs
Message-ID: <00a601bf324b$c9328310$1df96d8c@NT.JELLIFFE.COM.AU>


From: Tim Bray <tbray@textuality.com>

 > Meaning is  only conveyed by
>
> (a) running code, or
> (b) human-readable prose.
>
>To generate (a), you have to have (b) first.

I would go further than this, and say that if a) does not allow
retrieval of b), the system is not suitable for portions of a document
production chain in which human intervention is required. So, not only
direct documentation of the schema, but the schema should also provide a
minimal level of diagnostic information.

The systems THETIS and Schematron take the approach that a) and b)
should to a great extent be coupled. In Schematron, machine-processable
tests are attributes on text elements which state the assertion that is
being made.

I think there is a fundamental unresolved issue that there are lot of
situations in which we can use various kinds of schema validation
information: creating systems & tools, creating documents, validating
documents, giving error messages, giving diagnostics, triggering
defaulting behaviour, being used to allow logical combination of schema,
and so on.

To support these adequately, I believe a general-purpose schema language
has to not only tightly integrate human-readable components, but also
provide clear machine-processable enumerations of each possible error (&
categorizing it against som controlled vocabulary) in a way that allows
schema-processors to have a standard API that can be used to create
validators, editors, etc.  For an example of such an approach, see
proposal
http://www.ascc.net/xml/en/utf-8/error.html

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 04:48:35 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:17 2004
Subject: Parser compliance
In-Reply-To: <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>
	(message from Richard Lanyon on Thu, 18 Nov 1999 10:44:25 +0000 (GMT))
References: <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>
Message-ID: <199911190407.WAA00681@bruno.techno.com>

[Richard Lanyon:]
> On Wed, 17 Nov 1999, Steven R. Newcomb wrote:
> 
> > I have often wondered where this myth arose that DTDs are somewhere
> > between evil and useless.  It's baffling that this myth arises when
> > there's nothing better than, or even as good as DTDs.
> 
> It seems to me that the problem lies in what exactly DTDs are used /for/.
> Basically, DTDs are used for checking the structure of a document. While
> this is doubtless important, it seems to me to be curious that what is
> essentially an error-checking mechanism is the first thing that many
> people learn about XML. This in turn is because the important bit of XML
>  - viz designing hierarchical structures - becomes conflated in many
> people's minds with the syntax you use to error-check your structures.
> This is particularly worrying because in many cases the error-handling
> will be best dealt with by something familiar with the /semantics/ of the
> structure (i.e. a specific XML application) rather than by an XML parser.

I think we essentially agree, but I would like to put it another way.

In my own mind, the purpose of XML, as a tool, is to get information (not
just data) from A to B.  I think of information as having two forms:

(1) ready-to-run objects in memory, e.g. ready-to-roll DOM

(2) interchangeable (but otherwise useless) serialized-into-characters
    XML

XML parsers convert the syntactic components of information in form
(2) into information in form (1).  The conversion of
application-specific semantics requires something more than an XML
parser; the XML parser only moves the *syntactic components* of the
XML instance across the boundary between form (2) and form (1).  The
interesting thing here is that, for any information set, both forms
can be rigorously defined (not just form (2), which is quite
adequately definable via a DTD).  Any given set of applications can
usefully share a single meta-DTD and a single DOM-like (direct random
access to all nodes in the grove) abstract API to the semantics
intended to be interchanged by means of that meta-DTD.  All such
applications can share a single re-usable software module to perform
the conversion.  One desirable side-effect is that such re-usable
software makes applications much less expensive to write, and much
more likely to be able to reliably interchange information (not just
data) with each other.  These advantages are critical to both the
economic feasibility and the reliability of XML-mediated
business-to-business information interchange.

  (All this is standardized in HyTime (ISO/IEC 10744:1997) and is
   implemented in commercial software.  Some relevant jargon:
   inheritable architectures, meta-DTDs, base architectural instance
   extraction, architectural syntactic groves, architectural semantic
   groves, plug-in architecture engines, multiple architectural
   inheritance, architectural property sets, grove APIs.)

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 04:50:53 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:17 2004
Subject: documenting schemas/DTDs
In-Reply-To: <3.0.32.19991117202527.014d6b10@pop.intergate.ca> (message from
	Tim Bray on Wed, 17 Nov 1999 20:45:31 -0800)
References: <3.0.32.19991117202527.014d6b10@pop.intergate.ca>
Message-ID: <199911190319.VAA00675@bruno.techno.com>

[Tim Bray:]

> DTD's and XML Schemas both are *just syntax* 
> dammit, and syntax is not interesting.  XML, at the end of the day, is not 
> interesting.  Messages that convey meaning are interesting.  Meaning is 
> only conveyed by
> 
>  (a) running code, or
>  (b) human-readable prose.
> 
> To generate (a), you have to have (b) first.
> 
> End of the story. -Tim

I too am moved to underline this sentiment.   Hear!   Hear!   Hear!

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abisheks at india.hp.com  Fri Nov 19 05:28:44 1999
From: abisheks at india.hp.com (Abhishek Srivastava)
Date: Mon Jun  7 17:17:17 2004
Subject: Echo Fields
Message-ID: <001e01bf324e$d1d7c540$252f0a0f@india.hp.com>

Hi,

I am designing a client server system that exchanges data thru XML.
We have to implement something as "ECHO" Fields.

What this means is that,  in the request that the client sends to the server,
there are some fields that are marked as echo fields. Echo fields are optional fields when building a request
but, when included in the request, it becomes mandatory for the server to echo ( send back without modification)  them back, in the response.

For example  let's take a simple request. where the client send an employee number to the server, and the server returns the name of the employee.

<request>
<emplno echo="true"> 414021 </emplno>
</request>

The following is the valid response

<response>
<name> Abhishek </name>
<surname> Srivastava </surname>
<emplno echo="true"> 414021 </emplno>
</response>

If the server skips the emplno element then the response should not be treated as a valid document. And the parser should throw an exception as a mandatory field is missing.
However, if the client had not sent the emplno field in the request, then the emplno field would have been optional in the response.

How can this be done ?

regards,
Abhishek.    
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _/               Abhishek Srivastava
   _/                Hewlett Packard ISO       
  _/_/_/   _/_/_/    -------------------   
 _/    /   _/   _/     (Work)   +91-80-2251554 x1190
_/  _/   _/_/_/      (Ip)     15.10.47.37            
        _/           (Url)    http://sites.netscape.net/abhishes/index.html                        
       _/            
                     Work like you don't need the money.
                     Dance like no one is watching.
                     And love like you've never been hurt.
                     --Mark Twain                       
                     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991119/eb03d3f5/attachment.htm
From Mark.Birbeck at iedigital.net  Fri Nov 19 06:24:43 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:17 2004
Subject: Feeling good about SML
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E907B@sohos002.ied-support.net>

Robert La Quey wrote the following to me personally, but I hope he
doesn't mind me replying to the group. It's time I came clean!:
> Hi Mark,
> 
> I find this just a little odd coming from you, especially after the 
> fine (elegant, simple, cogent) arguments that you made for replacing
> DTDs with schemas. Everything I saw in your examples could be 
> performed in an SML that left out all off the stuff that Don listed,
> as well as the DTDs. 

It's true. But then I don't like DTDs. I can't handle all them funny
characters. I do use the Microsoft XML Schema preview though, because I
think the principles are sound, even if the spec is continuing to
evolve. In other words I think validation is an important issue.

> I do agree that for the vast majority of (even embedded) apps that
> the parser footprint is not an issue. Conceptual baggage is, and XML
> has a lot of stuff as you dig in that just is not essential.

To who?

> So your analogy is false. Breaks are essential. Non-skid 
> breaks are nice but not essential. DTDs are not essential.
> The ability to handle every encoding humankind has ever
> conceived of is not essential. 

It is. As well as the ones not yet conceived of.


> I think you are an advocate for an SML but just have not yet realized 
> that fact. 
> 
> I wonder, "Why?".

It's possible that I may be denying some inner desire to be pro-SML! But
I doubt it.

My point is based on an assumption that I haven't dared air in public
for fear of death threats. It is simply that it won't be that long
before there becomes little point in talking about XML 'as such'.

For example, I have developed a layer to allow my clients to update all
sorts of data on my server. The data is stored in a database, but
appears to be files to them, through a WebDAV interface. For the author
information stored in the database I use the XML version of vCard; for
the magazine articles I use XMLNews-Story; for the subjects that link
people and articles together I use Dublin Core, and to create contents
pages and publication information I use RDF. When PageMaker articles are
imported they get converted to XHTML before being converted to
XMLNews-Story. Oh, and SOAP is used to get some other bits and bobs from
another server.

Now, am I using XML? Well of course I am, but I'm also using binary,
electricity, RDBMS, C++, COM, blah blah blah. Sure, XML is still new
enough for it to have its own mailing list - just like electricity would
have done if it could have. But after a while you have to say that the
'concepts' of RDF, SOAP and WebDAV are something that is more than the
fact that they use XML for their implementation. Eventually XML will be
'seen' by the equivalent of particle physicists today. The rest of us
mere mortals will use their parsers, editors, class libraries,
protocols, and so on.

I feel that to a certain extent the point I am referring to may have
already arrived on this list. The guys on the WebDAV list, for example,
are not discussing whether their spec is too complicated. They're
getting on trying to solve conceptual problems. And we will all benefit
from it. I would have no problem, for example, seeing a discussion under
the general heading of XML about how we can build tools that 'hide' the
DOM from programmers. Microsoft just posted something like this up on
BizTalk. I'm still in two minds as to whether I could use this approach
in my code. What do others think? Or what about developing layers that
pull XML in and out of databases without other programmers needing to
worry about what's underneath?

Anyway, I do think we should aim up not down; rather than trying to
throw away stuff which is of fundamental significance, let's develop
things that make those important techniques easier to take advantage of.

Best regards,

Mark


Mark Birbeck
Managing Director
x-port.net Ltd.
220 Bon March? Centre
241-251 Ferndale Road
London
SW9 8BJ
w: http://www.iedigital.net/
t: +44 (171) 501 9502
e: Mark.Birbeck@iedigital.net

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 08:01:57 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:17 2004
Subject: Parser compliance
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain>
Message-ID: <3835039D.66E883A7@prescod.net>

David Megginson wrote:
> 
> That's probably a rhetorical question, but for those new to the field
> (i.e. who didn't come from SGML), SGML consultancies throughout the
> 1990's made an enormous portion of their money writing (and rewriting
> and rerewriting and rererewriting) massive and incomprehensible DTDs
> for government, military, and big industry, so naturally they (OK,
> "we") hyped the importance of DTDs as the cornerstone of any system.

There are two issues here. Tim raised one about how many mistakes DTDs
actually catch. You raise a (mostly unrelated, IMHO, one) about how much
of a project's energy should be spent on the DTD design. Even though you
are talking about different things, I think you're both wrong.

I claim that when people start using XML for what its good for schemas
(nee DTDs) will come back to the fore. After all, schema design is the
only hard thing about XML. The system design aspects are no different
than NON-XML system design. But for schemas, you could erase the "XML
here" box and put "s-expressions here" (or maybe even "CORBA here") and
nothing else would change.

Once the core standards mature, people will set about building vertical
schemas (they already have). They will spend an enormous portion of
money writing, and rewriting, and rewriting, massive and
incomprehensible DTDs for electronic commerce, manufacturing, three-D
graphics and so forth. It's precisely because getting these things right
is so hard AND so important that so much energy is spent on them. 

The XML world won't spend less money, it will just spend it differently.
Instead of several large, collosal failures, it will have dozens and
dozens of tiny failures (there are probably at least a dozen failed
XML-based languages already).

> In brief, then, SGML systems tend to be DTD-centric while XML systems
> tend to be component-centric.  There's nothing in SGML or XML that
> forces that distinction; it's just the way things fell out.  Tim's
> right -- DTD-based validation will tell you only a tiny portion of
> what's wrong with your document, though that portion can be helpful
> in some circumstances.

That's a massive generalization. I'll bet that if we cleaned up all
HTML, 80% of all errors would be caught by a well-formedness parser
(mandated by XML), and 80% of the rest would be caught by a validator.
Most of the remaining errors would be fixed if we ran an automated link
checker against them.

I think that Tim should spend some time getting to know Lauren's
customers. I would guess that most people in the document publishing
world who use validating editors and parsers cut their error checking
code by 9/10th. More important, they elevate the error checking into a
syntax that can easily be read and shared.

Your average XML editor purchaser has only two non-negotiable
requirements: realtime DTD checking and realtime stylesheet application.
Tim seems to think that they are naive but I don't believe so. That
feature can and does save many companies millions of dollars.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.


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



From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Nov 19 09:00:29 1999
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon Jun  7 17:17:17 2004
Subject: History
In-Reply-To: <Pine.LNX.4.10.9911182104500.4282-100000@eccnet.eccnet.com>
References: <3834A52A.477E@hiwaay.net>
	<Pine.LNX.4.10.9911182104500.4282-100000@eccnet.eccnet.com>
Message-ID: <14389.4456.835417.245028@spqr.oucs.ox.ac.uk>

Betty L. Harvey writes:
 > I give credit to Tim Berners-Lee
 > for the insight to recognize that SGML was format for the Web - HTML.  He
 > could have chosen NROFF, RUNOFF - any of those other system formatting
 > languages but he chose SGML - Thank you very much.

But he didn't choose SGML. He saw some SGML documents and borrowed
some of the look of it. I am sure that he would not claim that he
understood SGML at the time.

Sebastian Rahtz


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



From abisheks at india.hp.com  Fri Nov 19 09:26:36 1999
From: abisheks at india.hp.com (Abhishek Srivastava)
Date: Mon Jun  7 17:17:17 2004
Subject: parsing an XML document with comments
Message-ID: <00a701bf3270$189b9a80$252f0a0f@india.hp.com>

Hi,

I have written a program that searches an xml document for a particular element.
The problem is that it uses DOM. DOM will convert all the comments, white spaces etc. etc.
into Nodes thus slowing down my recursive search thru the tree.

Is there a way I can "switch off" the creation of these unwanted nodes. I agree that these 
are needed when u want to recreate a document from a dom tree, but that's not what i need !
I only want to "quickly" search an XML document for a particular tag.

Another Question : Does SAX also throw an event when it comes across a comment in the doc being parsed ?

regards, 
Abhishek.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _/               Abhishek Srivastava
   _/                Hewlett Packard ISO       
  _/_/_/   _/_/_/    -------------------   
 _/    /   _/   _/     (Work)   +91-80-2251554 x1190
_/  _/   _/_/_/      (Ip)     15.10.47.37            
        _/           (Url)    http://sites.netscape.net/abhishes/index.html                        
       _/            
                     Work like you don't need the money.
                     Dance like no one is watching.
                     And love like you've never been hurt.
                     --Mark Twain                       
                     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991119/34940a8e/attachment.htm
From ldodds at ingenta.com  Fri Nov 19 09:32:07 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:17 2004
Subject: External Entities A Field Guide (was RE: Feeler for SML (Simple         Markup Language))
In-Reply-To: <3834D497.8559E990@pacbell.net>
Message-ID: <000901bf3270$ce5583e0$ab20268a@pc-lrd.bath.ac.uk>

> > > "The *ONLY TIME* external parsed entities are the right thing to do is
> > > when exactly one actor is working on exactly one doucment and needs to
> > > partition it into separate files for *their own* convenience. *AT ALL
> > > OTHER TIMES* external parsed entities are not the right thing to use."
> > > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0238.html
> >
> > I quite strongly disagree with this, as does the practical experience of
> > many people on this list.
>
> Come to think of it ... doesn't the XHTML spec reuse parameter
> entities?  Those are "external parsed entities".
>
> In that case it'd be evil to have multiple copies of declarations
> for internal entites like "ldquo", "rdquo", "AElig" and so on.

Not guilty - I just pulled out some pointers from the 'evil parsed
entities thread'. Actually I was hoping for clarifications like this,
because I got the impression that some of the details may have
been lost in the overall debate.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From nisse at lysator.liu.se  Fri Nov 19 09:53:29 1999
From: nisse at lysator.liu.se (Niels Möller)
Date: Mon Jun  7 17:17:18 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
In-Reply-To: Tim Bray's message of "Thu, 18 Nov 1999 12:13:22 -0800"
References: <3.0.32.19991118121241.014e4ec0@pop.intergate.ca>
Message-ID: <nnemdm3j0m.fsf@sanna.lysator.liu.se>

Tim Bray <tbray@textuality.com> writes:

> At 09:57 AM 11/18/99 -0800, David Brownell wrote:
> >The technique I used in Sun's parser may be good for many folk to steal.
> >It involves using the standard Character.getType() method (which has
> >access to lots of Unicode tables, and in recent JVMs uses native code
> >to quickly access them) and then filtering that output by the rules in
> >the XML spec.   
> 
> Fine, but the Lark technique *doesn't* require storing any Unicode
> tables and thus uses an order of magnitude (probably) less memory; or
> am I missing something? -T.

Unicode tables are not *that* huge. I wrote some C code some months
ago. It associates 32 bits of character class information with each
unicode character (of which 22 are used). That includes most
properties of the unicode standard. I use a two level lookup table.

I.e. I first use the upper eight bits to index one primary table (256
bytes or 256 pointers). Each entry in this table points out one of 41
distinct subtables with the character class information for a block of
256 characters. So the tables sum up at slightly less than 42K. If you
can do with a subset of the unicode properties, say 4 bits, this
shrinks to about 6K, probably even less if the number of distinct
subtables decreases as well.

Compared to the binary search implementation that you estimate at
between 3.5K and 35K, I don't think the tables are excessive.

I don't count the code size, as the lookup function is trivial:

  int has_property(int mask, unicode c)
  { return secondary[primary[c/256]][c%256] & mask; }

I think this is a standard way to implement unicode character
properties. There might be more clever schemes that use less memory
for equally fast lookups; I chose this one because it was easy to
generate the needed tables automatically.

Regards,
/Niels


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 11:40:10 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:18 2004
Subject: About templates
In-Reply-To: <000201bf3234$56634de0$099918d1@docuverse1>
Message-ID: <000f01bf3282$b1c6db40$ab20268a@pc-lrd.bath.ac.uk>

> I am now leaning very heavily toward focusing SML on XML fragments
> so that SML data (the word 'document' is not in the SML draft spec)
> starts with the 'content' production rule of the XML spec.  No
> prolog, no misc.  SML data have zero or more elements and can be
> entirely text.

I assume you mean the following? 

[43] content ::= (element | CharData | Reference | CDSect | PI | Comment)*

So an SML data fragment is not necessarily a valid XML document 
as it can be entirely text? And so an XML processor may not be 
able to process an SML document? Is that correct?

> May your tire pressure remain constant,

And your mileage never vary :)

L.

==================================================================
    "Never Do With More, What Can Be Achieved With Less"
				---William of Occam
==================================================================
Leigh Dodds                             Eml:  ldodds@ingenta.com
ingenta ltd                             Tel:  +44 1225 826619
BUCS Building, University of Bath       Fax:  +44 1225 826283

HomePage :				 	http://www.bath.ac.uk/~ccslrd/
WebLog   :			     http://weblogs.userland.com/eclectic/
==================================================================

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



From tpassin at idsonline.com  Fri Nov 19 13:43:16 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:17:18 2004
Subject: Feeling good about SML
References: <A26F84C9D8EDD111A102006097C4CD0D0E907B@sohos002.ied-support.net>
Message-ID: <002901bf3294$7afcce00$45fbb1cd@tomshp>

----- Original Message ----- 
From: Mark Birbeck 

>. What do others think? Or what about developing layers that
>pull XML in and out of databases without other programmers needing to
>worry about what's underneath?

This is right o the money, Mark.

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 13:45:31 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:18 2004
Subject: Feeling good about SML
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E907B@sohos002.ied-support.net>
Message-ID: <001101bf3294$986b9840$099918d1@docuverse1>

Mark Birbeck wrote:
>Anyway, I do think we should aim up not down; rather than trying to
>throw away stuff which is of fundamental significance, let's develop
>things that make those important techniques easier to take 
>advantage of.

It seems that everyone is already shooting up and we are seeing too
many standards raining down on us to even keep track of, let alone
read.  Fundamental significance is questionable IMHO.  I can't remember
the last time I used notations.

I fear that there are more hairy standards and pseudo standards coming
down the pike that depends on PI, notations, DTD, etc.  One example is
DT4DTD which uses notations heavily for datatype constraints.

Why not use elements and attributes instead of using legacy mechanisms
like PI, entities, notations, DTD, etc?  XML style sheet association,
for example, uses PI because "use of a processing instruction avoids
polluting the main document structure with application specific
processing information."   Same reasoning forced the XML Namespace spec
to use the 'xmlns' attribute because attributes are useful for
'out-of-band' information.  Without it, we could have just used an
element to declare namespaces.

The concept of 'sacred main document structure' is a legacy of the SGML
world.  IMHO, it is a bad concept that encourages convoluted workaround
solutions.  SML will encourage people to break from the concept by
taking away the cumbersome alternatives.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rgl at decisionsoft.com  Fri Nov 19 13:30:19 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:18 2004
Subject: Feeling good about SML
In-Reply-To: <000301bf3245$239d5930$fad45dc7@ebt.com>
Message-ID: <Pine.LNX.4.10.9911191329090.16760-100000@localhost.localdomain>

On Tue, 16 Nov 1999, Gavin Thomas Nicol wrote:

> > For arguments sake, lets call this the XML Feature Manifest
> > (XMF).

> This seems like an excellent suggestion...  much better than
> inventing another language, and besides, the XFM would be
> great input into the SML analysis process.

I'd just like to add my support too! I think this is a great idea.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 13:53:03 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:18 2004
Subject: About templates
In-Reply-To: <000f01bf3282$b1c6db40$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <001d01bf3295$a5caa3e0$099918d1@docuverse1>

>> I am now leaning very heavily toward focusing SML on XML fragments
>> so that SML data (the word 'document' is not in the SML draft spec)
>> starts with the 'content' production rule of the XML spec.  No
>> prolog, no misc.  SML data have zero or more elements and can be
>> entirely text.
>
>I assume you mean the following? 
>
>[43] content ::= (element | CharData | Reference | CDSect | PI 
>| Comment)*
>
>So an SML data fragment is not necessarily a valid XML document 
>as it can be entirely text? And so an XML processor may not be 
>able to process an SML document? Is that correct?

Not correct.  My thinking is that there is no such thing as SML
document.  There is only SML data and there is no assumption that
SML data is stored anywhere or finite in length.  If SML data is
stored in a file and it is used as a well-formed external entity
from an XML document, it can be processed using XML processors.

The production rule is something like:

   SMLData ::= (element | CharData)*

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Fri Nov 19 13:58:43 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:17:18 2004
Subject: History
References: <3834A52A.477E@hiwaay.net><Pine.LNX.4.10.9911182104500.4282-100000@eccnet.eccnet.com> <14389.4456.835417.245028@spqr.oucs.ox.ac.uk>
Message-ID: <003101bf3296$9b108ea0$45fbb1cd@tomshp>


----- Original Message -----
From: Sebastian Rahtz <sebastian.rahtz@computing-services.oxford.ac.uk>


> Betty L. Harvey writes:
>  > I give credit to Tim Berners-Lee
>  > for the insight to recognize that SGML was format for the Web - HTML.
He
>  > could have chosen NROFF, RUNOFF - any of those other system formatting
>  > languages but he chose SGML - Thank you very much.
>
> But he didn't choose SGML. He saw some SGML documents and borrowed
> some of the look of it. I am sure that he would not claim that he
> understood SGML at the time.
>
> Sebastian Rahtz
>
>

Sebastian has beautifully illustrated my point from a previous post.  Many
(most, I'll bet) HTML writers looked at HTML pages and "borrowed the look"
of them - that's how they got started.  And it worked for them.  XML is
pretty much the same way, and it works too.  But you can't do C++, or SGML,
that way, for example.  You can't do everything this way that XML is capable
of either, but most people don't need to do everything.  Simplifying XML (or
really its use) will help to maintain the incredibly fast start it has had.
We shouldn't lose the simplicity in the name of the more complex uses, just
add optional layers.  This does seem to be the way things are going (schemas
and xslt being layered on top of xml, for example).

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 14:20:42 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:18 2004
Subject: Are you sure the XML decl shouldnt be a PI ? :)
In-Reply-To: <003901bf321d$f8358280$4a5eedc1@arp01>
References: <Pine.GSU.4.10.9911131656230.10423-100000@netcom17.netcom.com>
	<008701bf2e42$92747c50$4a5eedc1@arp01>
	<m34sepfeai.fsf_-_@localhost.localdomain>
	<006101bf2ecd$8b434c00$4a5eedc1@arp01>
	<m39040pujk.fsf@localhost.localdomain>
	<003901bf321d$f8358280$4a5eedc1@arp01>
Message-ID: <14389.23646.386270.874690@localhost.localdomain>

Richard Anderson writes:

 > BTW, I noticed that the XML recs in XML have these two entities:
 > 
 > <!ENTITY xmlpio "'&lt;?xml'">
 > <!ENTITY pic    "'?>'">
 > 
 > XML Pi Open, XML Pi Close maybe ? 

That may well be the way that the particular XML author thought of
them; they may also be relics from earlier drafts, before the
committee decided that the declaration was not a PI.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Fri Nov 19 14:17:27 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:18 2004
Subject: Feeling good about SML
References: <A26F84C9D8EDD111A102006097C4CD0D0E907B@sohos002.ied-support.net>
Message-ID: <00ab01bf3298$3d4dcd30$691d12d1@WORKGROUP>


----- Original Message -----
From: Mark Birbeck <Mark.Birbeck@iedigital.net>
To: 'Robert La Quey' <robertl1@home.com>; XML Dev <xml-dev@ic.ac.uk>
Sent: Friday, November 19, 1999 1:25 AM
Subject: RE: Feeling good about SML


>
> Anyway, I do think we should aim up not down; rather than trying to
> throw away stuff which is of fundamental significance, let's develop
> things that make those important techniques easier to take advantage of.

That's precisely what Don Park is doing -- trying to get us to figure out
what in XML is of "fundamental significance", and what is merely residue of
the SGML legacy and impedes understanding, implementing, processing, and
using XML in the real world.

> The guys on the WebDAV list, for example,
> are not discussing whether their spec is too complicated.
> They're getting on trying to solve conceptual problems

At the risk of decending into another "Frequently Flamed Topic", we can
applaud the W3C process that got an XML spec to the world in a timely
manner.  On the other hand, one reason the IETF isn't debating WebDAV's
bloatedness is because they spent a year or two publicly arguing about and
getting experience implementing drafts before the standard was cast in
stone.  (And, I might add, stripped it down to the point it doesn't even
have "versioning", even though that was part of the name of the activity).
The XML world got this experience *after* the spec came out ... and now
we're discussing what we've learned from it.

Is every bit of XML 1.0 of "fundamental significance"?  What are the
tradeoffs of offering a "legal" stripped-down version (or a mechanism to
negotiate the supported features between a document and a processor)? Does
footprint and processing speed matter in a world that will (some assert)
soon have cell phones with as much processing power as a 1994-vintage PC?  I
don't know, but it seems like a very worthwhile discussion 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From edwsm at us.ibm.com  Fri Nov 19 14:38:22 1999
From: edwsm at us.ibm.com (edwsm@us.ibm.com)
Date: Mon Jun  7 17:17:18 2004
Subject: documenting schemas/DTDs
Message-ID: <8525682E.00505A4D.00@D51MTA06.pok.ibm.com>

There's another school which holds that "syntax IS semantics".

A DTD for X.509 certificates allows me to express what parts of the
certificate I consider required, what parts of the certificate I consider
optional, as well as the legal forms of the parts themselves.

I can tell whether or not a certificate is valid, and also *why* (e.g. no
signature algorithm name was provided, the "not after" date was malformed).
I think that if I can answer "why" questions, I'm operating in the semantic
realm.

Meaning may only be conveyed (manifested?) in "running code or
human-readable prose", but the meaning is latent in the syntax, and
couldn't be conveyed if it wasn't already there.

Ed Smierciak



"Steven R. Newcomb" <srn@techno.com>@ic.ac.uk on 11/18/99 10:19:34 PM

Please respond to "Steven R. Newcomb" <srn@techno.com>

Sent by:  owner-xml-dev@ic.ac.uk


To:   tbray@textuality.com
cc:   xml-dev@ic.ac.uk
Subject:  Re: documenting schemas/DTDs



[Tim Bray:]

> DTD's and XML Schemas both are *just syntax*
> dammit, and syntax is not interesting.  XML, at the end of the day, is
not
> interesting.  Messages that convey meaning are interesting.  Meaning is
> only conveyed by
>
>  (a) running code, or
>  (b) human-readable prose.
>
> To generate (a), you have to have (b) first.
>
> End of the story. -Tim

I too am moved to underline this sentiment.   Hear!   Hear!   Hear!

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From robin at isogen.com  Fri Nov 19 15:21:25 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:18 2004
Subject: Parser compliance
In-Reply-To: <3835039D.66E883A7@prescod.net>
Message-ID: <Pine.GSO.3.96.991119085509.18255C-100000@grind>

Re:

> From: Paul Prescod <paul@prescod.net>
> To: xml-dev@ic.ac.uk
> Subject: Re: Parser compliance
> 
[David Megginson] wrote:
> 
> That's probably a rhetorical question, but for those new to the field
> (i.e. who didn't come from SGML), SGML consultancies throughout the
> 1990's made an enormous portion of their money writing (and rewriting
> and rerewriting and rererewriting) massive and incomprehensible DTDs
> for government, military, and big industry, so naturally they (OK,
> "we") hyped the importance of DTDs as the cornerstone of any system.

[Paul Prescod]
There are two issues here. Tim raised one about how many mistakes DTDs
actually catch. You raise a (mostly unrelated, IMHO, one) about how much
of a project's energy should be spent on the DTD design. Even though you
are talking about different things, I think you're both wrong.

[RCC]
It appears that all three of you are "right" within narrow contexts, but
that the questions/contexts are very different.  Being right or wrong
isn't important; communication is.

[Paul Prescod]
I claim that when people start using XML for what its good for schemas
(nee DTDs) will come back to the fore. After all, schema design is the
only hard thing about XML. The system design aspects are no different
than NON-XML system design. But for schemas, you could erase the "XML
here" box and put "s-expressions here" (or maybe even "CORBA here") and
nothing else would change.

[RCC]
In one respect I hope your prophecy comes true, but a lot is at stake
in how much "schemas (nee DTDs)" improve upon DTDs.  DTDs
are extremely limited in their relevance/utility WRT data modelling
because they cannot model semantics.  I would say that the "hard
thing" about the system design is getting the semantics right.  DTDs
don't help, "XML schemas" might help -- we'll see.

[Paul Prescod]
Once the core standards mature, people will set about building vertical
schemas (they already have). They will spend an enormous portion of
money writing, and rewriting, and rewriting, massive and
incomprehensible DTDs for electronic commerce, manufacturing, three-D
graphics and so forth. It's precisely because getting these things right
is so hard AND so important that so much energy is spent on them.

[RCC]
If design efforts revolve around "[incomprehensible] DTDs" then the
new age is no better than the old.  DTDs cannot express/capture the
the truly important features with respect to which "getting these
things right" is a relevant and critically important notion.  I agree
that massive amounts of energy are required.  But what tools
and methodologies are appropriate?  I don't think DTDs should
be seen, heard, smelled, tasted, touched, or even thunk upon during
analysis/design.  UML diagrams -- maybe.  Isn't this the problem?
As David says [elsewhere], it's a conundrum because conceptual
design tends to bump into implementation design.  What we need is
a language of conversation that works for the domain experts
(we want semantic transparency when we get to the UI), the system
designers, and the implementation designers -- *and* which
represents executable/testable code for competence/correctness
checking.  The requirements engineering community does this...

[Paul Prescod]
The XML world won't spend less money, it will just spend it differently.
Instead of several large, collosal failures, it will have dozens and
dozens of tiny failures (there are probably at least a dozen failed
XML-based languages already).

[RCC]
It would be an interesting investigation: why have a dozen
(or two) XML-based languaged "failed" already?  How would
the designers explain the failure?  How would their competitors?

[David Megginson]
> In brief, then, SGML systems tend to be DTD-centric while XML systems
> tend to be component-centric.  There's nothing in SGML or XML that
> forces that distinction; it's just the way things fell out.  Tim's
> right -- DTD-based validation will tell you only a tiny portion of
> what's wrong with your document, though that portion can be helpful
> in some circumstances.

[RCC]
"DTD-centric" vs. "component-centric" makes sense to
me, but "the way things fell out" begs for explanation. 
<warning>Avert your eyes, if you twitch and spaz out 
when someone claims there's a fundamental different
between vanilla "documents" and "database 
[components]".</warning>  If XML systems are indeed
"component-centric", is it not because the information
being carried by XML markup is a different "kind" of
information than is carried in traditional (1986-vintage,
static, paper-print, "documents")?  The information
substrate (the datatype) in the latter is "character text".
The characters in "content" represent themselves
directly, aggregated into morphemes, words, phrases,
sentences -- which find quintessential expression in
the mere display/print of these characters.  The data in
the leaf nodes are all (credits Gary Simons) "from the
same domain -- the domain of character text."
DTDs ("sort of") work for this application domain
because *printable character text* is inherently ordered
(serialized) and can often be delimited naturally by
markers representing a hierarchy, etc. etc.

Conversely: when I look at the 200 or so XML (putative,
proposed) applications
(http://www.oasis-open.org/cover/siteIndex.html#toc-contentsApps),
I see information modelled in many exotic domains
which are NOT quintessentially 'character text'.  In these
spheres of application, the most important features cannot
be captured/modelled/expressed using DTD language
(relationships and other semantics).  Will XML Schemas
[XML Schema Definition Language] change things
a little -- or a lot?  I can't tell yet from the Schema
specs. The last I looked, there was still no provision
for something as fundamental as constraining the
target of a referent (ID-IDREF mechanism in
current XML-speak);  *that* would represent two
steps toward first base.

If "DTD-based validation will tell you only a
tiny portion of  what's wrong with your document",
the reasons WHY differ with respect to "README,
PRINTME" documents and "databases."  The
question of the hour is whether XML schemas
will be able (politically) to redress the DTD situation.
I do not share the skepticism of some about
generalized, extensible facilities for modelling/validating
primitive (relational, ontologic) semantics in the
markup context.  Whether the W3C members will be able to
transcend partisan "company interest" issues to make this
design happen: we can pray.  If the energy spent on bashing
and trying to outflank MS were spent on Good Design, I have
no doubt that the committees could succeed.

[Paul Prescod, WRT DM's 'DTD-centric']
That's a massive generalization. I'll bet that if we cleaned up all
HTML, 80% of all errors would be caught by a well-formedness parser
(mandated by XML), and 80% of the rest would be caught by a validator.
Most of the remaining errors would be fixed if we ran an automated link
checker against them.

[RCC]  Maybe.  What kinds of "errors" are we talking about?  If
I can re-make Tim's point, or perhaps a related one:  a limerick
or sonnet can be represented in HTML with a typical HTML browser
client (html, div, ul, li, p).  But "errors" of interest to the
literature teacher are completely outside the scope of HTML.  An
error-checker that can address ONLY markup syntax is feeble in
the extreme, though certainly not useless.  But it's nearly irrelevant
with respect to the domain knowledge/information we hold to be
of principal importance.  DTDs didn't *have to be* that way, but
they are.  A matter of "grand equivocation," as I have discussed
elsewhere.

[Paul Prescod]
I think that Tim should spend some time getting to know Lauren's
customers. I would guess that most people in the document publishing
world who use validating editors and parsers cut their error checking
code by 9/10th. More important, they elevate the error checking into a
syntax that can easily be read and shared.

Your average XML editor purchaser has only two non-negotiable
requirements: realtime DTD checking and realtime stylesheet application.
Tim seems to think that they are naive but I don't believe so. That
feature can and does save many companies millions of dollars.

[RCC]
This emphasizes my point about the difference between XML as
created in XMetaL -- and XML as used in XMI, XOL, BRML, CBL,
fixML, and so forth.  And so, again: for printable text
(characters!) structured as vanilla documents via XMetaL, DTDs
and validating parsers give substantial payback, even if the
level of QA on information quality is zero to marginal.

I think what we want/need are conceptual modelling languages
and software tools that allow one to machine-test the correctness
of the design (the requirements, the system architecture, the
software modules).  Most critically: to model the semantics of
the problem domain -- something SGML/XML DTDs cannot do.  For
all the respect I have for SGML/XML, and DTDs [I have given a chunk
of my life in support of SGML!], and for all the pardon that should
charitably be granted to markup language design [1984] badly
botched in places [over the protest of computer scientists; so F.
 Chahuneau], I still have to agree with Tim and David 
about the serious inherent limitations.  I therefore hope
XML Schemas (Version 1 and Version [N]) will succeed in
helping migrate a very popular and accessible markup
notation in the direction of modern OO principles, where
semantics can be modelled directly.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 15:32:42 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:17:19 2004
Subject: External Entities A Field Guide (was RE: Feeler for SML (Simple
 Markup Language))
References: <000201bf3245$2265c390$fad45dc7@ebt.com>
Message-ID: <38356CB8.1899D3AF@isogen.com>

This is my statement and I stand by it. In my experience the at-scale
use of external parsed entities for re-use has only ever led to pain.

Gavin Thomas Nicol wrote:
> 
> > "The *ONLY TIME* external parsed entities are the right thing to do is
> > when exactly one actor is working on exactly one doucment and needs to
> > partition it into separate files for *their own* convenience. *AT ALL
> > OTHER TIMES* external parsed entities are not the right thing to use."
> > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0238.html
> 
> I quite strongly disagree with this, as does the practical experience of
> many people on this list.

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



From tpassin at mitretek.org  Fri Nov 19 15:36:02 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:19 2004
Subject: documenting schemas/DTDs
Message-ID: <008001bf32a3$afea7720$38a3f1ce@ls-.mitretek.org>


-----Original Message-----
From: edwsm@us.ibm.com <edwsm@us.ibm.com>


>There's another school which holds that "syntax IS semantics".
>
>A DTD for X.509 certificates allows me to express what parts of the
>certificate I consider required, what parts of the certificate I
consider
>optional, as well as the legal forms of the parts themselves.
>
>I can tell whether or not a certificate is valid, and also *why* (e.g.
no
>signature algorithm name was provided, the "not after" date was
malformed).
>I think that if I can answer "why" questions, I'm operating in the
semantic
>realm.
>
>Meaning may only be conveyed (manifested?) in "running code or
>human-readable prose", but the meaning is latent in the syntax, and
>couldn't be conveyed if it wasn't already there.
>

You can tell if the "not after" date is valid or not (syntax), but you
can't tell for what reason it has been included at all, what role it
plays in the system (semantics).  The meaning  is not "latent in the
syntax" at all.

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 15:52:29 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:17:19 2004
Subject: documenting schemas/DTDs
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16FB0@martinique>

> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com]
> Sent: Wednesday, November 17, 1999 10:46 PM
> 
> At 09:45 PM 11/17/99 -0600, W. Eliot Kimber wrote:
> 
> rewards repeated reading.  DTD's and XML Schemas both are 
> *just syntax* 
> dammit, and syntax is not interesting.  XML, at the end of 
> the day, is not 
> interesting.  Messages that convey meaning are interesting.  
> Meaning is 
> only conveyed by
> 
>  (a) running code, or
>  (b) human-readable prose.
> 
> To generate (a), you have to have (b) first.
> 
> End of the story. -Tim
> 

Oh no, stories never end.  Syntax is extraordinarily interesting, provided
you can map it to structures in some semantic domain.  That mapping is
what's missing (or rather, left implicit) in XML (and SGML).  And you forgot
option (c) formal specifications.  After all real engineers - the ones who
build things that don't break, i.e. not SW engineers - get along fine with
communication techniques that are neither computer programs nor informal
prose.  Formal specs ( Z is the most developed and widespread) are both
quite readable for humans and logically rigorous (and thus subject to
machine manipulation, e.g. typechecking).  Or can be; anything can be
misused.  For a good example take a look at "Object-Z Specification of the
CORBA Repository Server" at

	http://homepages.ulb.ac.be/~jcreal/techreport/tr-351.ps

If XML etc. were expressed in a language like Z, much of the confusion and
misunderstanding about various aspects of it would just disappear.  IMHO.

-gregg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Fri Nov 19 16:43:54 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:19 2004
Subject: How CAN one facilitate re-use of XML components? (was Re: External Entities A Field Guide )
References: <000201bf3245$2265c390$fad45dc7@ebt.com> <38356CB8.1899D3AF@isogen.com>
Message-ID: <013d01bf32ac$b257de90$691d12d1@WORKGROUP>

----- Original Message -----
From: W. Eliot Kimber <eliot@isogen.com>
To: Gavin Thomas Nicol <gtn@ebt.com>
Cc: <xml-dev@ic.ac.uk>
Sent: Friday, November 19, 1999 10:28 AM
Subject: Re: External Entities A Field Guide (was RE: Feeler for SML
(SimpleMarkup Language))

> This is my statement and I stand by it. In my experience the at-scale
> use of external parsed entities for re-use has only ever led to pain.

OK, so can I ask the list's opinion on what one CAN do to facilitate the
re-use of XML components produced by different authors or processes?  This
is one thing that XML is *supposed* to do well, if you believe various bits
of hype.

This is a topic that has confused me for years.  I've worked on this problem
from two directions, neither terribly successful.  First from the starting
assumption that the external parsed entity mechanism is too tricky and
fragile to support re-use, so we re-worked an editing/publishing product to
support the non-SGML/XML capabilities of underlying document management
systems here.  That was only partially successful, largely because it was
non-standard and difficult to translate to the diverse capabilities of the
various DMS systems.  The other was to try to more smoothly glue the XML
external entity mechanism onto the underlying repositories.  That was
frustrating and only partially successful for the reasons brought out in
these threads.

So is this something that simply has to be done by "whatever means
necessary" on the server/database side? Can databases or servers that
understand the XML entity resolution mechanism but also have version control
help? Will XLink save the day someday? Does the XML spec have to change (a
la Don's comments about facilitating fragment re-use in SML) to make this
happen, should the support go into some future DOM API, or what?

TIA ...




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



From mmclinn at cdt.com  Fri Nov 19 16:48:30 1999
From: mmclinn at cdt.com (Mike Mclinn)
Date: Mon Jun  7 17:17:19 2004
Subject: Representing Large Tabular Data Blocks
Message-ID: <38357F67.FA12FEAB@cdt.com>



Hello,

I am converting a number of existing proprietary file formats
to a general XML format.  The nature of the data I am working
with is very large, very well formatted blocks of data.
To give a point of reference, these files are used for data
transfer within the CAD industry.  

The natural XML solution would be of course to embed each
data value within an element or element attribute.  Such as:
<Point XYZ="324.1241 121.1214 -12.4521" NORMAL="0.0 0.0 1.0"/>
However, when you replicate this point element a hundred 
thousand times or so, you get an enormous increase in file
size.  Thus raising the question of XML efficiency.  

One possible solution is to compress the resulting files.
However, this is a very undesirable option in my case for
a variety of reasons.  Primarily compatibility and dependency
issues.

Another possible solution is to use a single element to bound
all points, using some sort of delimiters to separate records,
such as:
<Point TEMPLATE="XYZ,NORMAL,DT" DELIM="|">
324.1241 121.1241 -12.4521, 0.0 0.0 1.0, 0.707 0.707 0.0|
This works to some extent, though it seems a pretty drastic
break from standard XML data schemes.  Unfortunately, to
handle this nicely a customized parser is needed.  
Essentially, this method is providing a template or
macro encoded in an element attribute that defines the
contents of the element.  
	

Thus, if anyone could provide opinions / comments on the 
following issues, I'd be greatly appreciative:

Is there a good way of representing bulk data embedded in
an XML file, without relying on external compression for
efficiency?

Is the concept of using structured element contents 
a viable method in this case?


Thanks a lot!


Michael McLinn

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



From richard at cogsci.ed.ac.uk  Fri Nov 19 16:47:48 1999
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:17:19 2004
Subject: Are you sure the XML decl shouldnt be a PI ? :)
In-Reply-To: David Megginson's message of Fri, 19 Nov 1999 09:19:10 -0500 (EST)
Message-ID: <199911191647.QAA03489@rhymer.cogsci.ed.ac.uk>

> That may well be the way that the particular XML author thought of
> them; they may also be relics from earlier drafts, before the
> committee decided that the declaration was not a PI.

Incidentally, when XML is viewed as a subset of SGML, the XML
declaration *is* a processing instruction.  And if it weren't for
the need to be a subset of SGML, the syntax of the XML declaration
could have been completely different.

-- Richard



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 18:16:49 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun  7 17:17:19 2004
Subject: Representing Large Tabular Data Blocks
In-Reply-To: <38357F67.FA12FEAB@cdt.com>
Message-ID: <3.0.1.32.19991119131530.012ae8a0@tiac.net>


>The natural XML solution would be of course to embed each
>data value within an element or element attribute.  Such as:
><Point XYZ="324.1241 121.1214 -12.4521" NORMAL="0.0 0.0 1.0"/>
>However, when you replicate this point element a hundred 
>thousand times or so, you get an enormous increase in file
>size.  Thus raising the question of XML efficiency.  
>
>One possible solution is to compress the resulting files.
>However, this is a very undesirable option in my case for
>a variety of reasons.  Primarily compatibility and dependency
>issues.

Zlib can be statically linked to your code and is quite portable, so I'd
definitely recommend looking again at using compression.  All the fat of
XML just disappears when you zip it.  (However, you'll spend a lot of time
parsing all those tags in the receiver, so if perfomance is a goal, forget
this approach for large data sets.)

If you are really concerned with file size, it isn't clear why you would be
using ASCII to represent numbers.  How about encoding them as big-endian
IEEE single precision floating point, and then base-64 encoding the whole
mess.  That'll work out to 5.3 bytes per datum, which is less than your
examples are showing.  (Of course, you could use fixed point or some other
rep for the numbers to reduce their bits further.)


-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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 18:40:13 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:19 2004
Subject: How CAN one facilitate re-use of XML components?
In-Reply-To: "Michael Champion"'s message of "Fri, 19 Nov 1999 11:39:48 -0500"
References: <000201bf3245$2265c390$fad45dc7@ebt.com> <38356CB8.1899D3AF@isogen.com> <013d01bf32ac$b257de90$691d12d1@WORKGROUP>
Message-ID: <m366yy72dg.fsf_-_@localhost.localdomain>

"Michael Champion" <Mike.Champion@softwareag-usa.com> writes:

> > This is my statement and I stand by it. In my experience the
> > at-scale use of external parsed entities for re-use has only ever
> > led to pain.
> 
> OK, so can I ask the list's opinion on what one CAN do to facilitate
> the re-use of XML components produced by different authors or
> processes?  This is one thing that XML is *supposed* to do well, if
> you believe various bits of hype.

In the SGML world, Eliot Kimber wrote a very well-respected paper on
why separate documents (SUBDOCs) are better than references to
external parsed entities -- I no longer have the URL, unfortunately.

In general, if you want to reuse chunks of XML, there are enormous
advantages to something like

  <included-document src="foo.xml"/>

over

  <!ENTITY foo SYSTEM "foo.ent">

  ...

  &foo;

The XML linking people have done yeoman's (and woman's) work trying to
figure out standard attributes for specifying this kind of
relationship -- I've fallen behind, but perhaps Tim can let us know
where things are right now.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 18:55:24 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:19 2004
Subject: Parser compliance
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca> <m37ljh6lbs.fsf@localhost.localdomain> <383343AA.EBB9B115@allette.com.au> <m3so245ypz.fsf@localhost.localdomain>
Message-ID: <38357DEC.A0BE5B68@prescod.net>

David Megginson wrote:
> 
> > It's a bit disingenuous to criticise what was far and away the best
> > solution at the time. It was no more or less a money-grab than the
> > current market.
> 
> DTDs should have been just part of the solution, not *the* solution.

But why did these projects exist?

Let's say the US military wants to exchange parts information with the
Canadian government. This is a horrendous problem technically,
politically and economically. It would be a hundred million dollar
project (if it were ever completed) and the output would be not a single
line of software but rather an extremely large DTD or set of DTDs and a
very large design document. It seems massively unfair to act as if the
act of producing this specification is not "real work" because it is not
coding. 

A separate issue is which is more important: the document or the machine
readable DTD. Tim claims that the DTD is of minor importance. I would
argue even with that but it is still different than saying that the
effort that produced the DTD was itself a waste or a sham.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Orr at Design-Intelligence.com  Fri Nov 19 19:05:18 1999
From: Michael.Orr at Design-Intelligence.com (Michael.Orr@Design-Intelligence.com)
Date: Mon Jun  7 17:17:19 2004
Subject: History
Message-ID: <4454C011BDE5D211B6C800609776E540268AED@master.design-intelligence.com>

> -----Original Message-----
> From: Sebastian Rahtz
> Subject: Re: History
> 
> Betty L. Harvey writes:
>  > I give credit to Tim Berners-Lee
>  > for the insight to recognize that SGML was format for the Web - HTML.
He
>  > could have chosen NROFF, RUNOFF - any of those other system formatting
>  > languages but he chose SGML - Thank you very much.
> 
> But he didn't choose SGML. He saw some SGML documents and borrowed
> some of the look of it. I am sure that he would not claim that he
> understood SGML at the time.

Of course he understood it! 

He also understood that the *first* order of business was to create a 
hypertext page that everyone could read and write, because: 
(1) the value of that is an order of magnitude higher than all previous 
computer applications combined, 
(2) it was pragmatically achievable -- including world-wide viral 
distribution -- on top of the internet as it existed at the time, and
(3) that done, generalized markup could be added on top of a platform 
so compelling, economically and otherwise, that no organization would 
decline to adopt it. 

The most productive single insight in the history of the world. 

Do you think it's a coincidence that the adoption curve for markup looks 
like a step function?  
                               -------- (y = signif % of human activity)
                               |
                               |
                  (thousands of lines deleted)
                               |
                               |
SGML --- (infinite time) --- HTML (y = SE-intense structured publishing)

The ultrasimplifications in HTML brought some problems. They can be 
fixed, but they could not have been prevented without killing the goose. 

The cost of the retrofix is high enough to be painful to some of us 
who come from an engineering mindset, sometimes to the extent that it 
seems unjustifiable, leading to remarks characterizing HTML as a botch. 
This is called having one's eye too close to the page: nothing could be 
further from the truth. 

The role of XML is to converge full-powered, fully-leveraged, fully-
engineering-compatible computing back in. Its mission must be universal 
expressiveness, and it must commit to that as firmly as HTML committed 
to *its* mission of universal accessibility. 

The W3C process to date has executed admirably against this mission, 
and one thing that has helped tremendously is HTML's inborn, though 
imperfect and mostly unconscious, extensibility as an SGML-based 
language. 

This is also not a coincidence. 

Regards, 
Mike

----------------------------------------
Michael Orr, CTO, VP R&D
Design Intelligence Inc, Seattle WA USA
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 19 19:07:01 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:19 2004
Subject: SGML, XML and SML
References: <383233D8.46BC@hiwaay.net> <m3aeod6lug.fsf@localhost.localdomain> <38335F04.1303@hiwaay.net> <38336763.506679C7@prescod.net> <38349B4B.76EC@hiwaay.net>
Message-ID: <38357E6E.2616061D@prescod.net>

Len Bullard wrote:
> 
> suggested to the EDI committees that markup was preferable, it was
> dimissed as an irrelevant text format.  When I was at the PDES meetings
> when SGML was first considered, it was only as a string alternative
> to the somewhat byzantine document model they were building.  No, Paul,
> two things made the EDI folks take it seriously:  

The "EDI folks" are not the drivers of electronic commerce. GM is
partnered with CommerceONE and Ford is partnered with Oracle. The EDI
people are merely falling into line.

> Common LISP comes to mind.  S-expressions, as Dan Connoly told me, are
> the highest form.  Why not LISP?  Well, because HTML wasn't written
> in LISP.  As the twig is bent, so grows the tree.

LISP S-expressions have three problems:

 * even more stigma than SGML
 * as you say, angle brackets were king
 * no schema language

But yes, if Microsoft had backed s-expressions, XML would not be where
it is today. And nobody would be whining that XML is way too large and
complicated for many applications. That might be a good thing.
DSSSL-style S-expressions would be MUCH better for representing property
relationships than XML is, and property relationships are pretty central
to e-commerce and all sorts of machine to machine communication.

SML people: think on this.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Orr at Design-Intelligence.com  Fri Nov 19 19:13:49 1999
From: Michael.Orr at Design-Intelligence.com (Michael.Orr@Design-Intelligence.com)
Date: Mon Jun  7 17:17:19 2004
Subject: Feeling good about SML
Message-ID: <4454C011BDE5D211B6C800609776E540268AEE@master.design-intelligence.com>

> -----Original Message-----
> From: Richard Lanyon [mailto:rgl@decisionsoft.com]
> Subject: RE: Feeling good about SML
> 
> 
> On Tue, 16 Nov 1999, Gavin Thomas Nicol wrote:
> 
> > > For arguments sake, lets call this the XML Feature Manifest
> > > (XMF).
> 
> > This seems like an excellent suggestion...  much better than
> > inventing another language, and besides, the XFM would be
> > great input into the SML analysis process.
> 
> I'd just like to add my support too! I think this is a great idea.

I wholeheartedly agree with this. 

Regards,
Mike

----------------------------------------
Michael Orr, CTO, VP R&D
Design Intelligence Inc, Seattle WA USA
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From edwsm at us.ibm.com  Fri Nov 19 19:38:47 1999
From: edwsm at us.ibm.com (edwsm@us.ibm.com)
Date: Mon Jun  7 17:17:20 2004
Subject: documenting schemas/DTDs
Message-ID: <8525682E.006BE51C.00@D51MTA06.pok.ibm.com>

If I strip the syntax off of the message you sent me, it might become:

    The the the if for is is in in but has not "not after" all all,
    You you what what "latent in the syntax" at at reason date plays
    valid system meaning can can't included tell (syntax), (semantics).
been

I took your message and squeezed out the structure that is required for
well-formed English (The DTD if you will that controls how nouns, verbs,
adjectives, prepositions, etc. can be combined :-).  Your words lose their
meaning (semantics) without the structure (syntax) you used to organize
them.
Also, if you took the exact same words and organized them differently, the
result could be a valid English message with a completely different
meaning.  If meaning changes with structure, then I think that structure
must contain at least some of the meaning of a message.

Syntax matters.


Ed Smierciak




"Thomas B. Passin" <tpassin@mitretek.org>@ic.ac.uk on 11/19/99 10:35:19 AM

Please respond to "Thomas B. Passin" <tpassin@mitretek.org>

Sent by:  owner-xml-dev@ic.ac.uk


To:   <xml-dev@ic.ac.uk>
cc:
Subject:  Re: documenting schemas/DTDs




-----Original Message-----
From: edwsm@us.ibm.com <edwsm@us.ibm.com>


>There's another school which holds that "syntax IS semantics".
>
>A DTD for X.509 certificates allows me to express what parts of the
>certificate I consider required, what parts of the certificate I
consider
>optional, as well as the legal forms of the parts themselves.
>
>I can tell whether or not a certificate is valid, and also *why* (e.g.
no
>signature algorithm name was provided, the "not after" date was
malformed).
>I think that if I can answer "why" questions, I'm operating in the
semantic
>realm.
>
>Meaning may only be conveyed (manifested?) in "running code or
>human-readable prose", but the meaning is latent in the syntax, and
>couldn't be conveyed if it wasn't already there.
>

You can tell if the "not after" date is valid or not (syntax), but you
can't tell for what reason it has been included at all, what role it
plays in the system (semantics).  The meaning  is not "latent in the
syntax" at all.

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 19 20:20:52 1999
From: wunder at infoseek.com (Walter Underwood)
Date: Mon Jun  7 17:17:20 2004
Subject: Parser compliance
In-Reply-To: <199911190407.WAA00681@bruno.techno.com>
References: <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>
 <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>
Message-ID: <3.0.5.32.19991119112744.00aec6b0@corp.infoseek.com>

At 10:07 PM 11/18/99 -0600, Steven R. Newcomb wrote:
>
>In my own mind, the purpose of XML, as a tool, is to get information (not
>just data) from A to B.  I think of information as having two forms:
>
>(1) ready-to-run objects in memory, e.g. ready-to-roll DOM
>
>(2) interchangeable (but otherwise useless) serialized-into-characters
>    XML

This doesn't begin to cover a lot of what XML is used for. It does
cover document-like uses, but not the data-serialization uses.
In the latter, folks want their application objects, not objects
that accurately reflect the source document. They need something
more like marshalling/unmarshalling code, going straight to the
app-meaningful objects.

Even for some documentation-like uses, a DOM is the wrong answer.
Our search engine needs to extract text and store it in the indexes.
Analyzing the documents in a stream (SAX) means handling bigger
documents, using less memory, et cetera.

wunder
--
Walter R. Underwood
wunder@infoseek.com
wunder@best.com (home)
http://software.infoseek.com/
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Fri Nov 19 20:42:27 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:20 2004
Subject: About template. part 2
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEBKEHAA.martind@netfolder.com>

Hi,

As Isaac Asimov did for the robot world, let create some rules for the
semantic web.

The first phase of the Web saw the emergence of dynamically created HTML
pages. These pages are mostly constructed with template based tools (i.e.
Cold fusion, ASP, JSP, PHP, etc..). These template based tools include code
fragment or special elements to extract data from data sources. The role of
these code fragments is to convert data into rendition objects and more
particularly into HTML objects. The result of such process is a HTML
document ready for rendition by any HTML aware browser (more or less).

Rule 1:
-------
The semantic web will be based mostly on templates. These templates won't
produce presentation document (i.e. HTML) but model document (i.e. XML).
After being created or fetched from the server, the model document is then
sent to browsers. These latter, do the transformation from the model to the
presentation. Thus, contrary to the phase one web, template based tools will
be used to create the model on the server and the browser will convert it
into presentation.


Note:
----
 During the phase one web, the server sends one document to be interpreted.
The HTML document. During the phase two web, at least two documents are sent
to the browser: a) the model, b) the "render" method which takes the form of
a style sheet. We then have now an "object" containing data and a "render"
method. Later on, more methods may be added.

To be more precise, the two documents (i.e the model and the style sheet)
may not be physically separated but included into a single physical
document. However, it remains that the model is separated from the
presentation and more than one method can potentially be applied to the same
data on the client side. for instance, an E-check could be displayed in a
browser (the "render" method") and also posted to a local accounts
receivable module (the "post to accounts receivable" method).

Of course the image of a browser, present in our mind, is that of today's
browsers. But we can, as well, envision a "workflow" folder receiving the
document and this latter appearing as a file icon. A mouse click on the
document's icon may reveal all available methods like "render", "post to
accounts receivable", etc.. The code for these methods may come from the
net, be locally resident and matched to the document as long as a possible
matching could be made locally. Thus, the final object could be the assembly
of code locally or remotely resident. The methods assembly is based on a
match between the document and the local methods or accompanying the model
as sent by the provider.

Is this what we call a paradigm shift?

Hence, we'll move from:

     server					 Browser
template + data = HTML -----------> render HTML

to:

     server					       browser
template + data = XML -----------> XML+CSS or XML+XSL or xml+??

rule 2:
-------
The structure of the model is not known "a priori". The model document is
assembled from a collection of fragments. The final XML document is more an
aggregate than a document conforming to a fixed structure.

rule 3:
-------
During the aggregation process, the document "in progress" may not be
serialized as a text document but may take more the form of a hierarchical
structure manipulated through an API. The output sent to the browser,
though, will be serialized for the exchange process. The server role is then
a role of creating an XML document and the role of the browser to provide an
interpretation on this document. The most common interpretation being the
rendition for human consumption (i.e. get access to the information through
our senses).

Problems to resolve:
--------------------
Provide to the client solid pattern match tools so that local methods could
be matched to a particular data. This process is called "object assembly".
The object being finally assembled on the client side not solely on the
server side. Let's take again the example of the E-Check received in a
"workflow" folder. The rendition can be provided by the sender so that the
check appear on the user agent as the sender want it to appear (for brand
recognition and re-enforcement). The "post to accounts receivable" cannot be
coming from the sender and has to be provided locally. To do so, the local
agent has to be able to match the incoming model and the "post to accounts
receivable" methods available only on the local station. Hence the final
object assembled on the client side has one method provided by the sender
and one locally matched to the model. The local client sees an object with
these two methods: "render", "post to accounts receivable".

Possible issues I envision:
---------------------------
When part of a workflow, a model may vary in time. Thus, new fragments may
be added, actual fragments deleted or transformed. Thus, our notion of XML
documents as a static entity may be seriously handicapped when confronted to
a "data flow process" (for computer scientists) or a business or workflow
process (for business scientists). Can we envision an XML document with a
structure varying in time? We may have to if we want to create "data flow"
systems to model business processes (i.e. workflows).

Dreams are simply potential realities
unknown author.

Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From BBerck at ESPS.com  Fri Nov 19 20:48:51 1999
From: BBerck at ESPS.com (Ben Berck)
Date: Mon Jun  7 17:17:20 2004
Subject: Special characters in XSL pattern strings
Message-ID: <4139ED560536D3118F100008C7F36E451A8D53@HQMAIL>

I am trying to execute the following string using IE5 XML DOM's
selectSingleNode:
TAG[@PATH = "C:\test.txt" ]

This doesn't work, even though XML DOM returns that exact value for the
pattern: "TAG[0]/@PATH"

Other queries work, as long as they don't have a colon in them.

I tried encoding the : and . with &#58; and &#46;.  Didn't work.

I am currently using a work around.  Any news on this problem?

-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Friday, November 19, 1999 11:45 AM
To: xml-dev@ic.ac.uk
Subject: SGML, XML and SML


Len Bullard wrote:
> 
> suggested to the EDI committees that markup was preferable, it was
> dimissed as an irrelevant text format.  When I was at the PDES meetings
> when SGML was first considered, it was only as a string alternative
> to the somewhat byzantine document model they were building.  No, Paul,
> two things made the EDI folks take it seriously:  

The "EDI folks" are not the drivers of electronic commerce. GM is
partnered with CommerceONE and Ford is partnered with Oracle. The EDI
people are merely falling into line.

> Common LISP comes to mind.  S-expressions, as Dan Connoly told me, are
> the highest form.  Why not LISP?  Well, because HTML wasn't written
> in LISP.  As the twig is bent, so grows the tree.

LISP S-expressions have three problems:

 * even more stigma than SGML
 * as you say, angle brackets were king
 * no schema language

But yes, if Microsoft had backed s-expressions, XML would not be where
it is today. And nobody would be whining that XML is way too large and
complicated for many applications. That might be a good thing.
DSSSL-style S-expressions would be MUCH better for representing property
relationships than XML is, and property relationships are pretty central
to e-commerce and all sorts of machine to machine communication.

SML people: think on this.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991119/91b99f78/attachment.htm
From rev-bob at gotc.com  Fri Nov 19 22:42:48 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:20 2004
Subject: History
Message-ID: <199911191742764.SM01192@Unknown.>

> > But [TBL] didn't choose SGML. He saw some SGML documents and borrowed
> > some of the look of it. I am sure that he would not claim that he
> > understood SGML at the time.
> 
> Sebastian has beautifully illustrated my point from a previous post.  Many
> (most, I'll bet) HTML writers looked at HTML pages and "borrowed the look"
> of them - that's how they got started.  And it worked for them.

It works to a degree, sure.  If you want to do anything fancy with it, though, there's no 
better way than to learn the spec and go with it.  There are faster ways, and there are 
sloppier ways, but I argue that there is no *better* way.

When I first decided I wanted to make a web page, I picked up HTML For Dummies 
and went through it.  It gave me a basic idea of how things fit together; how HTML 
worked as a language.  (As it turns out, some of that information was wrong - but I 
learned that later.  One key goof involved TITLE and a matching H1 element, but that's 
off the topic.)  When I actually got down to the process of making that page, I whipped 
out my talismanic legal pad and did a literal markup job - I wrote what I wanted the first 
page to say, then indicated where I wanted to add links to later pages.  When I got home, 
I keyed that in and got working on it.  Yes, looking at source code was a big part of that 
process, especially when it came to using JavaScript...but when it came time to strike out 
on my own and start creating effects instead of simply aping what I could find elsewhere, 
the only way to do that was by getting a reference and using it.

Looking at source is a good way to get your feet wet; in fact, I may wind up scouting 
some DHTML source in the near future to get an idea of how I want to proceed with 
that.  The point is, it's a starting point...and that's all it should be.

> XML is pretty much the same way, and it works too.  But you can't do C++, or
> SGML, that way, for example.  You can't do everything this way that XML is
> capable of either, but most people don't need to do everything.  Simplifying XML
> (or really its use) will help to maintain the incredibly fast start it has had.
> We shouldn't lose the simplicity in the name of the more complex uses, just
> add optional layers.  This does seem to be the way things are going (schemas
> and xslt being layered on top of xml, for example).

In other words, we should simplify XML so a larger number of clueless people can 
misuse it more easily?

IMO, we already have an XML dialect for that audience.  It's called XHTML, and while 
it's not final yet, it really isn't too far off from "real" HTML...and yet, it gets people to 
notice things like well-formedness and strict syntax.  Frankly, I think the XHTML effort 
is as far as the "simplification" movement needs to go; if someone can't even be bothered 
to figure that dialect out, they probably can't be bothered to make a decent page in the 
first place.

Yes, I know that sounds really elitist of me - that may be because it IS elitist.  Probably 
comes from seeing too many "this is my cat's poetry" and "here's a list of Doom II cheat 
codes" pages.  I appreciate HTML being easy to learn, and I'm glad there are people out 
there who use this as an entry point, but I also see a lot of bad code out there.  With 
HTML being as simple as it is, I have to wonder about the intellectual capacity of people 
who get it badly wrong.  I'm sure they're good at something, but HTML ain't it - and 
oversimplifying XML in the name of attracting those people strikes me as analagous to 
saying that motorcycles should come with permanent training wheels because some 
people have bad balance.  If you have bad balance, use a car - because a motorcycle is 
the wrong choice for you.

Let's let the intellectually lazy people stick with HTML, where they can use FrontPage et 
al. to their hearts' content.  XML offers a prime opportunity to raise the bar a bit.  Yes, 
the full scope of XML is daunting - that's why you don't tackle it all right away.  Get it 
working a little at a time, work up gradually to a fully functional knowledge of the 
language.  If you don't want to use external entities because you don't grok 'em, fine - 
don't use them.  You don't need a special version of the language to put that constraint 
on you.

To close this out, here's an open question to all the "SML" supporters here.  Is there any 
part of what you want from SML that you could *NOT* get from writing a different 
form of documentation for XML?  (By which I mean, say you want no external entities, 
so you don't document them.)  What I'm getting at is that it may not be the spec itself 
that is of concern, but rather the documentation for that spec.  One person has said that 
by taking all the DTD stuff out of the XML spec, it was a lot easier to read.  Perhaps all 
this really means is that the DTD stuff could be moved to another part of the docs - it's 
still there if you want to get into it, but you don't feel the need to master it just to get 
your feet wet.  If the problem is the docs, write a simpler version and post it...but don't 
blame the language for having complex documentation.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at mitretek.org  Fri Nov 19 22:51:30 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:20 2004
Subject: Representing Large Tabular Data Blocks
Message-ID: <00a301bf32e0$88ec16a0$38a3f1ce@ls-.mitretek.org>

Mike Mclinn asked:
>
>I am converting a number of existing proprietary file formats
>to a general XML format.  The nature of the data I am working
>with is very large, very well formatted blocks of data.
>To give a point of reference, these files are used for data
>transfer within the CAD industry.
>
>The natural XML solution would be of course to embed each
>data value within an element or element attribute.  Such as:
><Point XYZ="324.1241 121.1214 -12.4521" NORMAL="0.0 0.0 1.0"/>
>However, when you replicate this point element a hundred
>thousand times or so, you get an enormous increase in file
>size.  Thus raising the question of XML efficiency.
>

It looks like you want to parse out the XYZ data after you remove them
from the XML.  You have 40 characters of data (including the point's id,
"XYZ" in this example, and 22 mark-up-related characters.  This is an
overhead of about 33%.  It's not an "enormous" overhead, but it's
noticable.  Since you are not using XML to describe the substructure of
points, you could abbreviate the names:
    <Pt XYZ="324.1241 121.1214 -12.4521" NRM="0.0 0.0 1.0"/>

This gives you 16 characters of non-data, or 29%.  If the NORMAL vector
used 8 digits for each component instead of 3 as in the example (which I
imagine is usually the case), you would have an overhead of 16/71, or
22%.

Do you really need to worry about 22% in the file size?  If so, you
could express your numbers in base 26, say, to reduce the number of
digits.  Just as binary expession makes the numbers very long,  This
would probably reduce every 3 characters to 2.  But with or without this
encoding, you still have to have another non-XML parser for the actual
data components.

If you have to write the parser, you can do anything, but if you are
feeding an existing parser, you may think you have to live with this
format.

It all depends on your needs, of course.  I would suggest that 22%
overhead is acceptable.


>One possible solution is to compress the resulting files.
>However, this is a very undesirable option in my case for
>a variety of reasons.  Primarily compatibility and dependency
>issues.
>
>Another possible solution is to use a single element to bound
>all points, using some sort of delimiters to separate records,
>such as:
><Point TEMPLATE="XYZ,NORMAL,DT" DELIM="|">
>324.1241 121.1241 -12.4521, 0.0 0.0 1.0, 0.707 0.707 0.0|
>This works to some extent, though it seems a pretty drastic
>break from standard XML data schemes.  Unfortunately, to
>handle this nicely a customized parser is needed.
>Essentially, this method is providing a template or
>macro encoded in an element attribute that defines the
>contents of the element.
>
>Thus, if anyone could provide opinions / comments on the
>following issues, I'd be greatly appreciative:
>
>Is there a good way of representing bulk data embedded in
>an XML file, without relying on external compression for
>efficiency?
>
>Is the concept of using structured element contents
>a viable method in this case?
>


Regards,

Tom Passin


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



From rev-bob at gotc.com  Fri Nov 19 23:26:57 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:20 2004
Subject: Representing Large Tabular Data Blocks
Message-ID: <199911191826187.SM01192@Unknown.>

> I am converting a number of existing proprietary file formats
> to a general XML format.  The nature of the data I am working
> with is very large, very well formatted blocks of data.

Is it formatted well enough that you can write a scrap of code to retrieve element N at 
random?

> The natural XML solution would be of course to embed each
> data value within an element or element attribute.  Such as:
> <Point XYZ="324.1241 121.1214 -12.4521" NORMAL="0.0 0.0 1.0"/>

Actually, I'd see that more intuitively as:
<point x="324.1241" y="121.1214" z="-12.451" nx="0.0" ny="0.0" nz="1.0"/>

More granularity, y'know?

> However, when you replicate this point element a hundred 
> thousand times or so, you get an enormous increase in file
> size.  Thus raising the question of XML efficiency.  

I seem to remember seeing in the XML spec that brevity in code size was not a major 
design concern; its selling points were clarity and interchangeability.

One thing I could suggest, if your NORMAL spec is the default that it appears to be, you 
could define that default value in the tag definition.  I'd really have to see a block of 
elements to make a solid conclusion there, though.

> Another possible solution is to use a single element to bound
> all points, using some sort of delimiters to separate records,
> such as:
> <Point TEMPLATE="XYZ,NORMAL,DT" DELIM="|">
> 324.1241 121.1241 -12.4521, 0.0 0.0 1.0, 0.707 0.707 0.0|

First up, the whole concept of defining a delimiter character is antithetical to XML 
theory; the tags are supposed to be containers and/or atoms which delimit themselves.  
Hence, the whole "tag" structure; a tag is structural, thus it delimits and/or contains data.

> Is there a good way of representing bulk data embedded in
> an XML file, without relying on external compression for
> efficiency?

Not that I am aware of; XML was not designed for code brevity.

> Is the concept of using structured element contents 
> a viable method in this case?

You mean like your second example?  No, I wouldn't say so.

One thing I do note is that you seem to have two or three sub-elements with identical 
structure; you have three coordinates representing, respectively, an X, Y, and Z value.  
Hence, it may make greater lexical sense to use one element to represent that triplet, and 
another element outside it to assign relative values.  For instance:

<point>
<coords x="324.1241" y="121.1241" z="-12.4521" type="xyz"/>
<coords x="0.0" y="0.0" z="1.0" type="normal"/>
<coords x="0.707" y="0.707" z="0.0" type="dt"/>
</point>

Another thing to consider is that, if you have the same original data file that you can pass 
around to other systems, and if you can write a platform-independent scrap of code (you 
know, the one I mentioned earlier?) to extract and parse a given element from that data 
file, you may be able to use that code as the low-level interface between the data and a 
virtual XML document.  Hence, instead of reading an actual static document, the agent 
requests that the interface give it element N in XML format.  The interface scans the 
data file for the Nth line, reads it, internally converts it into a format like one of those 
above, and spits that back to the agent as a response to the request.  Apply a cache 
system, and this could work pretty well.  Since you'd still be using that original data 
format at the core (or an optimized conversion of that format), you shouldn't see any 
footprint growth outside that taken up by the interface and the agent module.  If you're 
looking at a one-time lump conversion from the original format to another for your future 
use, you can have the interface handle the XML and use the conversion to make the 
new data format something your interface can more easily (and quickly) handle.  At that 
point, you can either store the core file and the interface in a central location (having the 
interface function as the ultimate administrator) or distribute copies and find a way to 
reconcile/distribute changes regularly.  I'd advise the former.  ;)

In other words, you'd just be moving a key bit of the logic.  Instead of reading the full 
XML file and extracting an element, you move to the next higher level of abstraction 
(sorry, but I just had to work that in) and tell the extraction call to ask the interface for 
that element instead of doing the grunt work of pulling the element itself.  Since the 
interface is delivering one element at a time, it doesn't need to keep the data around in 
full-fledged XML format - it only needs to deliver the data in that format, and the 
extraction call need never know that there's NOT a full XML document.  Odds are, 
you'd wind up not only saving disk space, but processing time and disk wear as well.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gkholman at CraneSoftwrights.com  Fri Nov 19 23:51:11 1999
From: gkholman at CraneSoftwrights.com (G. Ken Holman)
Date: Mon Jun  7 17:17:20 2004
Subject: Announce: Sixth Edition of XSLT/XPath Tutorial Materials
Message-ID: <4.2.0.58.19991119184801.00c2acd0@pop1.attglobal.net>

Announce: Sixth Edition of XSLT/XPath Tutorial Materials

   Practical Transformation Using XSLT and XPath
   (XSL Transformations and the XML Path Language)
   Sixth Edition - 1999-11-19 - ISBN 1-894049-03-9
   Copyright (c) 1999 Crane Softwrights Ltd.
   310 Pages / Subscription price includes free updates

New in the comprehensive Sixth Edition:

(1) - all constructs of the W3C Recommendations for XSLT 1.0 and XPath 1.0 
are documented

(2) - illustrations have been updated with new content in response to 
comments and questions

(3) - a ZIP file is provided with all of the XML and XSLT sample files used 
in the book

(4) - the reference annexes in the free preview excerpt download have been 
updated to the REC and to the latest version of XT

As with our other editions of this XSLT training material, the purchase of 
any edition of this publication entitles the customer to any future edition 
of the same material.  Note that the work on this material *has not 
stopped* ... work will continue on a prose version of the book, formatted 
with XSL (while I begin writing the "Practical Formatting Using XSL" material).

Information can be obtained from the link below to the "Commercial Training 
Materials" section the Crane web site (also the location of the free 
preview download).

For those of you who have already downloaded the free excerpt preview, you 
may wish to download a new one with the revised diagrams and 
annexes.  Also, if you only had access to US-letter sized in the past, you 
can now download the preview in A4 size.

.............. Ken

p.s. Attention existing customers:

You all should have received your update notice by now, but some email 
addresses are bouncing.  If you do not receive your update notice soon, 
please forward a copy of your receipt in order to obtain the latest 
username/password for download.

cc:
XSL List
XML-DEV
XML-L
XML-EDI
comp.text.xml
microsoft.public.xml

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-03-9
Next instructor-led training:              1999-12-05/06, 1999-12-07,
-                            2000-02-27/28, 2000-05-11/12, 2000-05-15


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 00:12:15 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:20 2004
Subject: SGML, XML and SML
In-Reply-To: <38357E6E.2616061D@prescod.net>
Message-ID: <001601bf32ec$2d1b55a0$099918d1@docuverse1>

>But yes, if Microsoft had backed s-expressions, XML would not be where
>it is today. And nobody would be whining that XML is way too large and
>complicated for many applications. That might be a good thing.
>DSSSL-style S-expressions would be MUCH better for 
>representing property
>relationships than XML is, and property relationships are 
>pretty central
>to e-commerce and all sorts of machine to machine communication.
>
>SML people: think on this.

I don't understand what 'this' is.  Are you suggesting that SML should
be abandoned in favor of S-expressions or are you saying that S-expressions
didn't fly so SML won't either?

FYI, SML does not have the three problems.  It is just hairless XML.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 02:21:41 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:20 2004
Subject: About template. part 2
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAKEBKEHAA.martind@netfolder.com>
Message-ID: <000001bf32fe$481b64a0$099918d1@docuverse1>

>Possible issues I envision:
>---------------------------
>When part of a workflow, a model may vary in time. Thus, new 
>fragments may be added, actual fragments deleted or transformed.
>Thus, our notion of XML documents as a static entity may be
>seriously handicapped when confronted to a "data flow process"
>(for computer scientists) or a business or workflow process
>(for business scientists). Can we envision an XML document with a
>structure varying in time? We may have to if we want to create 
>"data flow" systems to model business processes (i.e. workflows).

Looks like we are heading toward same goal via different mental
track.  The word 'document' invokes too many preconceived notions
to be used in this context, I believe.  XML stream is more like it.
XML stream that changes its structure over time requires dynamic
schema with ability to redefine, augment, remove schema fragments.

Implementation wise, this is rather simple.  Have client dynamically
download schema fragment-specific handlers.  Security is no problem
since they are restricted to operations on the stream itself.  Java
is a perfect fit for this.

>Dreams are simply potential realities unknown author.

I think dreams are brain farts but I your description *sounds*
better. <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jackson at dstc.edu.au  Sat Nov 20 06:46:14 1999
From: jackson at dstc.edu.au (David Jackson)
Date: Mon Jun  7 17:17:20 2004
Subject: How CAN one facilitate re-use of XML components?
Message-ID: <383643FB.193318DF@dstc.edu.au>

David Megginson wrote:
> In the SGML world, Eliot Kimber wrote a very well-respected paper on
> why separate documents (SUBDOCs) are better than references to
> external parsed entities -- I no longer have the URL, unfortunately.

Is this the one?

  Re-Usable SGML: Why I Demand SUBDOC
  http://www.isogen.com/papers/e.subdoc.htm

Just sitting near the top of one of my many piles of things to
(re)read.

David Jackson
DSTC
Brisbane Australia

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 10:58:44 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:21 2004
Subject: Feeling good about SML
Message-ID: <003601bf3349$ad5bd890$5df96d8c@NT.JELLIFFE.COM.AU>


From: Michael Champion <Mike.Champion@softwareag-usa.com>

>Does
>footprint and processing speed matter in a world that will (some
assert)
>soon have cell phones with as much processing power as a 1994-vintage
PC?  I
>don't know, but it seems like a very worthwhile discussion to me!

And there is the question of how can a toaster have enough grunt to
handle TCP/IP enough to connect to the WWW yet be so short of space that
it cannot squeeze a little XML parser in :-)  If SML is not intended for
web use, then I think it should  be discussed in comp.text.sgml or
comp.text.

The reason SGML has so many optional features is because there were so
many people who just *had to have* something to make their life simpler.
Everytime someone says "I don't like PIs" or "I don't like DTDs" or "I
don't like external entities" or "I don't like non-ASCII" it raises the
largely bogus spectre of XML 1.1 or XML 2,0 or whatever.  It would be a
sad day to see the SGML declaration reappear as XFM. I

Everything that anyone is saying now has been said before when XML was
designed, and indeed a lot of it was apparantly said when SGML was
designed.  Of course over time the tradeoffs  differ, in partiular with
new media.

But why this endless "not invented here" desire to reinvent XML. It is
still a mystery too me.  The complication in the XML world is not XML
1.0, but namespaces (which means that an element names may mean
different things in different contexts) and class-based schemas (which
can mean that even within a namespace a name may mean different things
depending on context).  Anyone who thought DTDs were hard may be in for
a shock unless we are careful!

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 11:11:10 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:21 2004
Subject: SGML, XML and SML
Message-ID: <006901bf334b$7178f720$5df96d8c@NT.JELLIFFE.COM.AU>

 From: Don Park <donpark@docuverse.com>

 >
>FYI, SML does not have the three problems.  It is just hairless XML.

Well, it is not XML at all if  it miss-parses a well-formed XML
document.

<a>
    <?b </a> ?>
    <!-- </a> -->
    <![CDATA[ </a> ]]]>
</a>

If you go ahead with SML, you should at least use different delimiters
to make sure that there is no confusion.

And you will immediately find that your co developers will say
"end tags take up so much space".  In XML, we can say "oh, but
when they are compressed, having explicit end-tags does not take
up extra space; besides we want them for error checking and to
make life simpler for people parsing using PERL and regular
expressions".

But you cannot answer that, because your toaster has too little space to
fit an XML parser, so it cannot fit a compression utility (or TCP/IP
anyway,
as I mentioned), so the resulting design will be some single character
delimiter.  So the resulting language will look something like SGML
NET-tags:
    <a/hellow world/
or LISP:
    (a  "hello world")
or RTF:
    {a hello world}


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 11:32:50 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:21 2004
Subject: SGML, XML and SML
In-Reply-To: <006901bf334b$7178f720$5df96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <3.0.6.32.19991120111538.009b15e0@gpo.iol.ie>

At 07:35 PM 11/20/99 +0800, you wrote:
> From: Don Park <donpark@docuverse.com>
>
> >
>>FYI, SML does not have the three problems.  It is just hairless XML.
>
>Well, it is not XML at all if  it miss-parses a well-formed XML
>document.
>
Ah, but as I understand it (correct me if I'm wrong SML guys),
the idea is to make SML an "application profile" of XML 1.0.

Any SML doc is an XML doc but not the other way around.

	SML < XML < SGML


regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 11:29:34 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:21 2004
Subject: Feeling good about SML
In-Reply-To: <003601bf3349$ad5bd890$5df96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <3.0.6.32.19991120111211.009e62c0@gpo.iol.ie>

[Rick Jelliffe]
>
>The reason SGML has so many optional features is because there were so
>many people who just *had to have* something to make their life simpler.
>Everytime someone says "I don't like PIs" or "I don't like DTDs" or "I
>don't like external entities" or "I don't like non-ASCII" it raises the
>largely bogus spectre of XML 1.1 or XML 2,0 or whatever.  It would be a
>sad day to see the SGML declaration reappear as XFM. I
>
Why would it be a sad day?

	1) XML parsers differ in important ways
	2) Knowing the differences is useful for XML developers

It seems to me to be a no-brainer to conclude:

	3) Having an agreed upon way to document the differences 
	for both human and software consumption is useful.

No?

regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 12:57:34 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:22 2004
Subject: SGML, XML and SML
In-Reply-To: <006901bf334b$7178f720$5df96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000001bf3357$1b138a60$099918d1@docuverse1>

>Well, it is not XML at all if  it miss-parses a well-formed XML
>document.
>
><a>
>    <?b </a> ?>
>    <!-- </a> -->
>    <![CDATA[ </a> ]]]>
></a>

Rick, I think you are actually picking an example favoring
the use of SML.  It might be legal XML but it is also a
bracketed ball of mess.  Besides, SML processors can't
parse full XML just as XML parsers can parse full SGML.

>If you go ahead with SML, you should at least use different delimiters
>to make sure that there is no confusion.

To whose benefit should SML giveup interoperability with XML?

>But you cannot answer that, because your toaster has too 
>little space to fit an XML parser, so it cannot fit a compression
>utility (or TCP/IP anyway, as I mentioned), so the resulting design
>will be some single character delimiter.  So the resulting language
>will look something like SGML NET-tags:
>    <a/hellow world/
>or LISP:
>    (a  "hello world")
>or RTF:
>    {a hello world}

Who is to say future toasters will have too little space to fit
an XML parser?  Maybe future appliances will use a chipset with
XML parser in silicon.  Chances are that the chip designers will
not waste chip space to support full XML parser.

Frankly, I would rather appreciate assistance and helpful advices
rather than arguments against SML.  There is really zero chance of
me giving up until the SML spec is finished and ignored politely.

To make things interesting, I'll eat a copy of the SML spec if SML
doesn't fly.  Will you guys (you know who you are) each eat a copy
of the XML spec?  I think 12 point fonts should make enough of a meal.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 20 13:15:27 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:22 2004
Subject: SGML, XML and SML
In-Reply-To: Sean McGrath's message of "Sat, 20 Nov 1999 11:15:38 +0000"
References: <3.0.6.32.19991120111538.009b15e0@gpo.iol.ie>
Message-ID: <m3ogcp5mqn.fsf@localhost.localdomain>

Sean McGrath <digitome@iol.ie> writes:

> Any SML doc is an XML doc but not the other way around.
> 
> 	SML < XML < SGML

That gets you into the subset dilemma: all conformant XML processors
will be able to handle SML, but not all conformant SML processors will
be able to handle XML.

Perhaps it's worth the cost, and perhaps not -- that's up to you guys
(and, eventually, the market) to decide -- but there *is* a cost.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From reschke at medicaldataservice.de  Sat Nov 20 17:33:02 1999
From: reschke at medicaldataservice.de (Julian Reschke)
Date: Mon Jun  7 17:17:22 2004
Subject: SGML, XML and SML
In-Reply-To: <m3ogcp5mqn.fsf@localhost.localdomain>
Message-ID: <NCBBIPMOPKLLGKJPBINCIEELDFAA.reschke@medicaldataservice.de>

> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> David Megginson
> Sent: Saturday, November 20, 1999 2:14 PM
> To: xml-dev@ic.ac.uk
> Subject: Re: SGML, XML and SML
>
>
> Sean McGrath <digitome@iol.ie> writes:
>
> > Any SML doc is an XML doc but not the other way around.
> >
> > 	SML < XML < SGML
>
> That gets you into the subset dilemma: all conformant XML processors
> will be able to handle SML, but not all conformant SML processors will
> be able to handle XML.

Why would that be a dilemma? That was exactly the goal, correct?

I really think it would be A Good Thing to have a common name for XML minus
a list of features...



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



From martind at netfolder.com  Sat Nov 20 20:39:37 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:22 2004
Subject: Funny things about XML gizmos
Message-ID: <NBBBJPGDLPIHJGEHAKBAMECIEHAA.martind@netfolder.com>

Hi,

Having still XML gizmos ideas screeming for taking life on the electronic
metaphor of the letter. I will then let them live an little and let them
share some of their funny problems (are XML gizmos new wave Pocamons? :-)

Still about biztalk and a workflow process let's the XML gizmo talk by
itself .

Note: before going any further and letting the biztalk XML gizmo take the
scene, I should mention that the URN used for biztalk XML gizmos is quite
weird and totally against the spirit of those who participated to the URN
creation (including your humble servant). It seems that the guy who created
the biztalk URN was playing truant (i.e Hooky) with the URN school and
confounded URLs with URNs. Anyway, he's not alone in that case :-))


<?xml version="1.0"?>
<BizTalk xmlns= "urn:schemas-biztalk-org:BizTalk/biztalk-0.81.xml">
<Route>
<From locationID="111111111" locationType="DUNS"
process="" path="" handle="3"/>
<To locationID="222222222" locationType="DUNS"
process="" path="" handle="23CF15"/>
</Route>
<Body>
<my-e-business xmlns="urn:schema:e-biz0.56">
<?xml-stylesheet text="text/xsl" href="mystylesheet.xsl" media="screen"?>
.... the my-e-business content ..........
</my-e-business>
</Body>
</BizTalk>

In fact here the biztalk XML gizmo is a routing container for my-e-business
XML gizmo. If the biztalk XML gizmo would be a simple container I would have
the above gizmo. But...wait a minute. (here we go, why is this guy still not
on his bike instead of .../%$? - its my Karma ;-)

If I consider the biztalk gizmo as a document as it would be interpreted by
an XML browser, what then is the scope of the xml-stylesheet processing
instruction? a) the whole document, b) the document fragment
<my-e-business>. I would be inclined to think that XML browsers implementers
would pick the option (a) because nothing is said about the scope and thus,
implicitly the scope is applied to the whole....document.

But, in our case, the whole XML gizmo is in fact a russian doll where the
biztalk gizmo is a container for the my-e-business XML gizmo. Thus, what the
XML browser expect is:

<?xml version="1.0"?>
<?xml-stylesheet text="text/xsl" href="mystylesheet.xsl" media="screen"?>
<BizTalk xmlns= "urn:schemas-biztalk-org:BizTalk/biztalk-0.81.xml">
<Route>
<From locationID="111111111" locationType="DUNS"
process="" path="" handle="3"/>
<To locationID="222222222" locationType="DUNS"
process="" path="" handle="23CF15"/>
</Route>
<Body>
<my-e-business xmlns="urn:schema:e-biz0.56">

.... the my-e-business content ..........
</my-e-business>
</Body>
</BizTalk>

And the XML browser will consider the whole construct as a document to be
rendered not, in fact,  as a russian doll containing a smaller one. Each
doll being also a separate entity. The encapsulation doll is like an
Ethernet packet containing other kinds of packets (like for instance an IP
packet). Or to keep my russian doll analogy, the outer doll contains a
smaller one but each doll is a separete doll. By removing the inner doll and
putting it beside the outer doll, it is then obvious that both are separate
things.


	-------------------------------------------------------
	| Routing envelope						|
	|									|
	|	-----------------------------------------		|
	|	| my-e-business content				|	|
	|	|							|	|
	|	------------------------------------------	|
	|									|
	-------------------------------------------------------

The XML browser and the style sheet implicit rule force the inner doll to be
aware of the outer doll. Thus, the stylesheet will have to be designed in
such ways that the my-e-business elements are contained in something else.
Beware of absolute node's references!

But wait a minute... (again...Hummm I am gonna break his bike on his head
:-)))
Let's say that at one point of the workflow process, there is a task agent
wanting to mention that its content is displayable and adds a style sheet to
the XML gizmo. The task station will have then to insert it for the whole
document and not the fragment. But we have a problem... Let's the workflow
engine explain himself what is his problem....

Now let's say that the workflow engine want to be a good boy and help his
owners to promote their brand througout the workflow process. After all, the
humans said around him, that a major benefit of XML compared to less well
borned species is the fact that, for the first time, the marshalled content
between task agents can be rendered by a standard language (note: And I
personnaly find this great!). Our poor workflow engine is a bit embarrassed
because the content that he has to transport has to be rendered its own way.
On the other hand, his owners ask that their own brand and own rendition
style to be used by the XML browser. Of course, our workflow engine owners
where savvy enough to format the layout so that the other contained layout
wouldn't look too foolish.

Can you help the workflow engine? he's having trouble to please its owners
and the owners of the content he's carrying. What should he do. He received
something like

<?xml version="1.0"?>

<?xml-stylesheet type="txt/xsl" href="MyOwnnersStyle.xsl" media="screen"?>

<BizTalk xmlns= "urn:schemas-biztalk-org:BizTalk/biztalk-0.81.xml">
<Route>
<From locationID="111111111" locationType="DUNS"
process="" path="" handle="3"/>
<To locationID="222222222" locationType="DUNS"
process="" path="" handle="23CF15"/>
</Route>
<Body>
<my-e-business xmlns="urn:schema:e-biz0.56">

<?xml-stylesheet type="text/xsl" href="mystylesheet.xsl" media="screen"?>

.... the my-e-business content ..........
</my-e-business>
</Body>
</BizTalk>

Two style sheets, his owners' one and the customer's one.

His good friend told him that he has to resolve intelligently the situation
by creating himself a single stylesheet because the XML browser is aware
only of a whole construct named document. Poor workflow engine, he's
confused because he has to deal with fragments. If you where in the shoes of
the workflow engine what would you do? (please remember that a strike is not
allowed in the workflow engine universe :-))

Tanks for your help
signed: a puzzled  workflow engine,

Cheers
a human having fun with paradoxes and real life situations creating
paradoxes
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From stark at corp.phone.com  Sun Nov 21 00:19:17 1999
From: stark at corp.phone.com (Peter Stark)
Date: Mon Jun  7 17:17:22 2004
Subject: Using namespace prefix in attribute values
Message-ID: <000701bf33b6$7ead3c10$8b161fc6@pstark.uplanet>

I am considering using namespace prefixes in attribute values. I know that
some new W3C Recommendations do this. What I want is attribute values that
are globally unique; in my case, name of events. Are there any other
solutions I should consider, or is this the best with available technology?

<eventListener
	type="q:eventname"
	xmlns:q="urn:myevents">

	..do something..

</eventListener>


Pros:
+Attribute values can be globally unique.

Cons:
-The XML processor may not provide the namespace prefix to the application;
the application will get "q:eventname" but will not be able to find out to
what namespace "q" was bound to in the document.

Strawman's proposal:
What are the disadvantages of, in a DTD or schema, define a "QNAME"
attribute type?


Thanks,

Peter
Phone.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 21 01:13:32 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:22 2004
Subject: facts, conclusions, and exhortations re XML (long)
Message-ID: <199911210111.TAA00461@bruno.techno.com>


>From an internal Microsoft memo (I copied this material from
http://www.opensource.org/halloween/halloween1.html):

  Open Source Software (OSS) projects have been able to gain a
  foothold in many server applications because of the wide utility of
  highly commoditized, simple protocols. By extending these protocols
  and developing new protocols, [Microsoft] can deny OSS projects
  entry into the market.

Open source is just one very small segment of the marketplace that is
being deliberately poisoned by Microsoft's efforts to "de-commoditize"
the protocols and services on which business relies.  I believe the
economic and social benefits of XML are all at stake here.  XML, as a
general-purpose markup syntax, can succeed wildly in the marketplace
even while the bulk of the potential benefit of XML -- human
productivity enhancement by the competitive operation of an open
market for information services -- is in the process of being snatched
from humanity's grasp by a single U.S. corporation.  It is not enough
that XML can be parsed everywhere by everyone.  The potential benefit
of XML is that it will allow any *knowledge* to be transferred by
anyone to anyone else.  That can only happen under one of two
circumstances:

* if the protocols and services that enable knowledge transfer are
  commoditized (virtually all people who love the Web prefer this
  possibility), or

* if all the important protocols and services are totally controlled
  by a worldwide de facto monopoly (Microsoft prefers this
  possibility, as long as the monopoly belongs to Microsoft).

I ran across more evidence of Microsoft's anticompetitive behavior
recently.  Most of you probably already knew about it.  XPath, as
implemented by Microsoft, provides access to the first node of any
nodelist as the zeroeth node (the node in the list that is addressed
by an array index value of 0), while the relevant W3C draft requires
it to be the first (index value of 1) node.  This means that with
Microsoft's implementations, no node (i.e., no information component)
address that is based on nodelist position will be resolved to the
same node that any strict W3C implementation would resolve it to.
This means that XSL stylesheets that use this feature of XPath will
not function the same way on IE5 as they will on W3C-conforming
browsers.  If this is an example of the "de-commoditization of
protocols and services" game that Microsoft is playing, an off-by-one
difference is both simple and effective.  Stylesheets can be written
in standard XSL and XML (so any validation process will regard them as
perfectly valid), but, even so, they can't reliably cross the border
between Microsoft-land and W3C-land, in either direction.  Thus,
Microsoft de-commoditizes stylesheet services, while relying on its
market dominance to keep and protect its market dominance.  This is a
Bad Thing For Everyone.

I believe that the primary purpose of XML is precisely to commoditize
information interchange services, for the purpose of making universal
information interchange practical, without requiring that the world
submits to an authoritarian IT regime like Microsoft's.  Effectively
"de-commoditizing" the use of XML is precisely what Microsoft (and
other technology businesses than gain power on the scale of
Microsoft's) will always attempt to do.

We XML developers have a moral obligation to recognize and report that
the de-commodization of XML is Microsoft's self-evident and documented
strategy, and that it is a strategy intended to cause Microsoft to win
while causing the public to lose.  It is a strategy born of
unimaginative, pessimistic and fearful zero-sum thinking.  Thus,
Microsoft demonstrates that it is unworthy to have so much influence
over civilization's future directions.

The only weapon we have against Microsoft's abuse of the public's
confidence is the truth.  The truth is also the only weapon that's
needed.  Let us wield that weapon vigorously.  If you feel that you
can't tell the truth about Microsoft's deliberate undermining of the
goals of the XML community without incurring financial or other costs,
I'd ask you to consider the following questions:

(1) Will lying or truth-telling be more costly for you?  (Consider
    *all* the costs of lying and/or remaining silent, including the
    cost in self-respect.)

(2) It is absolutely certain that someday you will die, at which point
    you will have no money and no further ability to make any choices
    at all.  You will leave behind only the lingering effects of how
    you chose to live your life.  Will you leave behind a world that's
    better or worse on account of the role you chose to play in its
    ever-unfolding story?  Will humanity be richer, or will it be
    poorer?  Specifically, will people have more useful access to
    their heritage as human beings (i.e., information and knowledge),
    or less?  That's what's at stake here, no more and no less.  If
    you don't believe that what you do (or don't do) will make any
    difference to future generations, you are mistaken.  You are an
    XML developer!

Below are some excerpts from "The Present Crisis" by James Russell
Lowell (1819-1891).  This poem had considerable impact on much of the
U.S. public's conscience just prior to the American Civil War.  (Some
of its verses later turned up in at least one popular Protestant hymn,
"Once to Ev'ry Man and Nation".)  Lowell was urging brave action in
opposition to the institution of human slavery, but "The Present
Crisis" covers much more territory than that.  There is always a
"Present Crisis".  No generation can avoid deciding which "ancient
goods" have now become "uncouth".

   [...]
   
   Truth forever on the scaffold, Wrong forever on the throne,--
   Yet that scaffold sways the future, and behind the dim unknown,
   Standeth God within the shadow, keeping watch above his own.
   
   We see dimly in the Present what is small and what is great,
   Slow of faith how weak an arm may turn the iron help of fate,
   But the soul is still oracular; amid the market's din,
   List the ominous stern whisper from the Delphic cave within,--
   ``They enslave their children's children who make compromise with sin.''
   
   [...]
   
   They have rights who dare maintain them; we are traitors to our sires,
   Smothering in their holy ashes Freedom's new-lit altar fires;
   Shall we make their creed our jailor? Shall we, in our haste to slay,
   From the tombs of the old prophets steal the funeral lamps away
   To light up the martyr-fagots round the prophets of today?
   
   New occasions teach new duties; Time makes ancient good uncouth;
   They must upward still, and onward, who would keep abreast of Truth;
   Lo, before us gleam her camp-fires! we ourselves must Pilgrims be,
   Launch our Mayflower, and steer boldly through the desperate winter sea,
   Nor attempt the Future's portal with the Past's blood-rusted key.
   
Why do I quote from "The Present Crisis"?  It's because I'm asking you
to consider: How should an information economy (which is quite
obviously, at least in this Present Crisis, "the Future's portal")
work, actually?  What is the role of XML in bringing about an
information economy that maximizes the opportunities available to
everyone, and that maximizes the possibility than everyone can benefit
from everyone's exploitation of those opportunities?  What roles
should major corporations have, and what would constitute abuses of
their power?  Perhaps most importantly, what constitutes public
education in a technological milieu where the best teachers can
enormously increase their own productivity?

In a worldwide information economy, information reform certainly just
as important as land reform has ever been in any previous human
civilization or economy.  Who will work the land (create and maintain
information), who will collect the taxes, and who will provide the
services?  How will innovation be encouraged, protected, accommodated,
and benefitted from?

One way to pay taxes is to be forced to buy new software every few
years.  But what if the services that the taxes are supposed to pay
for are suboptimal, or distributed unfairly or unwisely?  What if the
tax collectors line their own pockets with obscene amounts of money
and power, at the worldwide public's involuntary expense?  Terrible
wars have been declared and fought over much less.  Will we have to
undergo a second Great Depression, or worse, before we'll figure out
how to organize and operate the information/knowledge equivalents of
the priesthoods of the Federal Reserve Bank or the International
Monetary Fund?

My wish and exhortation is that all XML developers would proclaim:

  "Information owners and users of the world, unite!  Insist that the
   software and systems you buy are built to guarantee that the value
   of your information cannot be diminished merely by technological
   change, or by the caprices of would-be world dominators (in Redmond
   or elsewhere), or by the fortunes of your software providers.
   Quite literally, you have nothing to lose but the product
   differentiation barriers that jeopardize your economic security and
   progress."

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 21 01:29:11 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:22 2004
Subject: History
References: <Pine.LNX.4.10.9911182104500.4282-100000@eccnet.eccnet.com>
Message-ID: <383749A9.63EA@hiwaay.net>

Betty L. Harvey wrote:
> 
> Personally, I give credit to Yuri Rubinsky, President of SoftQuad until
> his untimely death, to the birth of XML. 

Agreed.  Yuri was influential in most SGML decisions at that time.  He
worked tirelessly.  In this, Charles was the hard headed standards
editor, 
and Yuri was the diplomat.  I miss him.

> I give credit to Tim Berners-Lee
> for the insight to recognize that SGML was format for the Web - HTML.  He
> could have chosen NROFF, RUNOFF - any of those other system formatting
> languages but he chose SGML - Thank you very much.

Yes.  Good call.

> Before I worked for the CALS program I was
> told that working in CALS was a dead-end to your career.

It paid for educations and it was in the initiative where many of us 
learned the ways of making standards and how to live in motels.   :-)

> When the Web came into existance I was working in CALS within the Navy and
> with our local Technology Transfer czar at David Taylor Model Basin.  I
> was positive that SGML could not work at a reasonable cost and effort
> within a large organization, such as DoD. T

This is where we disagree.  As a contractor to David Taylor, USAMICOM, 
and a lead designer of the CASS system, from 1986 to 1996, I worked 
around or on many of the Tri-Service IETM projects.  With the exception 
of the B-series bombers which were *near-black* security, there are 
few of these systems I did not study directly.  They all worked, Betty.  

I was there.  For every bloody inch of it.   The HTML you showed 
me was fantastic because it handled multi-media and because 
it WAS internet enabled.  Few IETM systems were although IADS ran 
fine on Novell.  That was precisely the struggle being in the 
IETM community.  It was meant to be for non-public systems so 
all of the work we did on projects like Beyond The Book metaphor 
were studied but not accepted.  (OTOH, that one is coming back 
if GEAE has their way.)

The problem was we could not standardize on one system and, we were 
being required to in a Tri-Service NIH frenzy of funding and control. 
Ultimately, we ran out of time... and interest.
   
Expensive?  Yes.   But the cost coming down was not XML or HTML:  it 
was 50 cent memory and two dollar processors.   We already had
stylesheet 
based browsers, and well-formed rules for handling instances.  We had 
server-side examples such as the General Dynamics and Lockheed Ft Worth 
systems.  It was working.  It was not esoteric.  It did require one to 
be an able document systems pro to set up and run. 

Sell them?  Heck no.  Everyone had Interleaf.  Then we got hit with 
the first wave of ATOS output to transfer to the IETMs.  Worked
perfectly.

The idea of using the Internet for IETMs died in the 
discussions of GOSIP.  That was TimBLs contribution:  he got a markup 
based system and a web protocol for hyperlinking out first.  There were 
no innovations in that;  but the timing was marvelous.

> I tried to talk the Navy into modifying
> Mosaic code (it was public domain) to support IETMs.  The climate
> wasn't right in 1994 for heresy. Today most IETM projects are
> Web based.

Right.  I can support that enthusiastically now, particularly now 
that with DHTML/XHTML as the client standard, and XML for the kinds of 
things we needed for 87269, it works. Heck, now we even have the 
X family of standards for stylesheets, linking, and so on.  Big 
fun and mortals get to do now what once only the DoDsters 
had and then, only if they were on the right projects.  Progress.

But Mosaic did not meet the requirements.  It was only 
when a scripting language became available internally and 
server side HTML became widely available that the web browsers 
met the requirements for IETMs particularly, 87279 DB-like.  
US MID came closer than both because it was defined precisely 
to meet those requirements.  The fact is, HTML became the 
only viable economic solution.  That is what Megginson asserts 
for XMLs triumph and I agree.  I just have the further heretical 
opinion that without Microsoft there at the very beginning, the 
odds that XML would succeed were little to none. 
It doesn't matter.  I think it is a viewpoint that is correct 
and casts a realistic light on some of the XML hype.

> It does distress me that now that XML has become popular that the pioneers
> are forgotten, especially Yuri.  He was a man who impacted not only the
> web but people positively.  He was a real visionary.  I also believe he
> would be really pleased about the current XML efforts.

Yes.  But he would be the first I think, to quickly acknowledge the 
heritage that XML has, that while some can call themselves inventors 
and co-inventors, it is reinvention.  Better to be known as the leaders 
who took what was and made it better.  That is what XML is.  The 
reasons for that don't matter.  The History does.  Respect is a duty.
 
> XML is becoming prolific because it is a good technology and people
> (computer scientists and marketeers) can understand it.  

Yes.  That is an achievement and it took leaders to make that happen.

> In conclusion - thanks Charles, Yuri, TimBL and many others for their
> vision!

Yes.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 21 01:28:58 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:22 2004
Subject: About template. part 2
References: <NBBBJPGDLPIHJGEHAKBAKEBKEHAA.martind@netfolder.com>
Message-ID: <38373FBB.104C@hiwaay.net>

Didier PH Martin wrote:
> 
> Can we envision an XML document with a
> structure varying in time? We may have to if we want to create "data flow"
> systems to model business processes (i.e. workflows).

Sure.  Think at the level of a single element type and it's immediate 
tree fully expanded (no entities).  One issue that seriously impeded 
acceptance of SGML application languages was that they became hideously 
complex.  Break the schema/DTD whatever, up into the smallest portions 
practical and think of aggregates of much smaller namespaces; put these 
together can considering them coordinate subsets that can be combined 
by intersections of shared types.  Write DTDs dynamically to reflect 
process and DFD interaction.  

I agree with Eliot and David about the lack of follow through on systems 
engineering using SGML or XML.   There is not much change in the 
practice; just the representation.  Most systems engineering
methodologies 
resolve to relational schemas (E-R).  W need a methodology that 
resolves to a multidimensional database where aggregate element types 
can represent dimensions and cells.  Then, time is just one of the 
dimensions of that description, and nicely, the one that is most 
stable because its hierarchy is clean.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 21 02:11:17 1999
From: schen at falconwing.com (Sean Chen)
Date: Mon Jun  7 17:17:22 2004
Subject: facts, conclusions, and exhortations re XML (long)
In-Reply-To: <199911210111.TAA00461@bruno.techno.com>
Message-ID: <Pine.LNX.3.96.991120205655.29374A-100000@www.falconwing.com>

Hi Steven, everyone,

Unbelievably, I'm defending Microsoft here, but:

On Sat, 20 Nov 1999, Steven R. Newcomb wrote:

...
> I ran across more evidence of Microsoft's anticompetitive behavior
> recently.  Most of you probably already knew about it.  XPath, as
> implemented by Microsoft, provides access to the first node of any
> nodelist as the zeroeth node (the node in the list that is addressed
> by an array index value of 0), while the relevant W3C draft requires
> it to be the first (index value of 1) node.  This means that with
> Microsoft's implementations, no node (i.e., no information component)
> address that is based on nodelist position will be resolved to the
> same node that any strict W3C implementation would resolve it to.

I believe the the implementation talked about here is XQL, a precursor to
XPath.  Nowhere has Microsoft claimed to implement XPath yet, AFAIK.  In
fact, according to Microsoft, they are refusing to implement XSLT or XPath
until the final recommendation, which has only just happened this week.

If this problem occurs, after these implementations come out, then we can
complain =)

We must be careful with our facts.  The problem with XML is that the dust
is just settling (or not, with XSchemas yet to be done) and there are a
lot of experimental work out there that is still hanging around.

. . . 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jamesr at steptwo.com.au  Sun Nov 21 02:12:34 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:17:23 2004
Subject: SGML, XML and SML
In-Reply-To: <NCBBIPMOPKLLGKJPBINCIEELDFAA.reschke@medicaldataservice.de
 >
References: <m3ogcp5mqn.fsf@localhost.localdomain>
Message-ID: <4.2.0.58.19991121130550.00cd1d60@203.41.126.17>

At 04:32 21/11/1999 , Julian Reschke wrote:

> > Sean McGrath <digitome@iol.ie> writes:
> >
> > > Any SML doc is an XML doc but not the other way around.
> > >
> > >     SML < XML < SGML
> >
> > That gets you into the subset dilemma: all conformant XML processors
> > will be able to handle SML, but not all conformant SML processors will
> > be able to handle XML.
>
>Why would that be a dilemma? That was exactly the goal, correct?
>
>I really think it would be A Good Thing to have a common name for XML minus
>a list of features...

I think the point is:

If something is XML, it handles all valid XML
documents.

Or it doesn't, and it isn't.

If SML cannot support all XML constructs, it
isn't XML. In the same way that XML is not SGML.

That's not to say that SML may not have
value in itself. It's just that a number of
posters have been more than a little lax in
their use of "XML" in regards SML.

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
Illumination: an out-of-the-box Intranet solution

http://www.steptwo.com.au/
jamesr@steptwo.com.au

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 21 05:02:42 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:23 2004
Subject: SGML, XML and SML
In-Reply-To: <4.2.0.58.19991121130550.00cd1d60@203.41.126.17>
Message-ID: <000101bf33dd$f1083860$099918d1@docuverse1>

>If something is XML, it handles all valid XML
>documents.
>
>Or it doesn't, and it isn't.
>
>If SML cannot support all XML constructs, it
>isn't XML. In the same way that XML is not SGML.

We never said SML is XML.  SML is a subset of XML.
Specifically, it meets the production rule of the
external parsed entity minus CDATA section, PI, and
comments.

You are right that SML is not XML in the same sense
that XML is not SGML.  That reasoning only justifies
a distinguishable name away from XML.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Sun Nov 21 06:14:39 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:23 2004
Subject: About templates
In-Reply-To: <000201bf3234$56634de0$099918d1@docuverse1>
Message-ID: <NBBBICMNIPCICMKJECCBIEPPDBAA.jelks@jelks.nu>

Don Park wrote:

> I am now leaning very heavily toward focusing SML on XML fragments
> so that SML data (the word 'document' is not in the SML draft spec)
> starts with the 'content' production rule of the XML spec.  No
> prolog, no misc.  ...

What's interesting is that one of the major reasons for introducing "Namespaces"
was fragments,  yet Namespaces' complexity is the largest cause of this hubbub
over SML.

Take a look at Canonical XML <http://www.w3.org/TR/xml-c14n>.  Look at all how
*all* the constructs are represented, then compare all of them put together with
just how Namespaces alone are represented.

/Jelks




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



From jelks at jelks.nu  Sun Nov 21 06:13:09 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:23 2004
Subject: Baroque CSS  (was: Why do we write standards?)
In-Reply-To: <AA4C152BA2F9D211B9DD0008C79F760A5CA3A1@odin.cromwellmedia.co.uk>
Message-ID: <NBBBICMNIPCICMKJECCBAEPPDBAA.jelks@jelks.nu>

Bill dehOra wrote:

> I see some standards that are verging on the Baroque. CSS comes to mind,
> maybe CORBA. CSS is way ahead of anything anyone is implementing right
> now and the features are being piled on for CSS3.

"Baroque" is a good word; in the case of one major W3C Working Draft, "Broke" is
better.  With "Behaviorial Extensions to CSS" <http://www.w3.org/TR/becss>, we
might as well just do away with MIME types altogether and declare everything to
be text/whatever -- it certainly makes a mockery of text/css (reminiscent of
what happened to text/html...).  The "extensions" are inserted directly in the
CSS, like this (from the WD):

	@script {
	  var count = 0;
	  function checkCount() {
	    if (document.getElementsById("radio").value == "add") {
	      count++;
	    }
	    else {
	      count--;
	    }
	  }
	}

It get's even more, uh, Baroque ...

	<STYLE>
	/* Link all DIVs with a CLASS of "fly"
	   to the "flyin" component */
	DIV.fly { behavior: url("flyin.htc"); }
	</STYLE>

(No, that wasn't pulled from some "designer d00d's" page, that's right out of a
W3C Working Draft, invalid HTML and all!!!).

And for the ultimate in Baroqueness, check out the section on "HTML Components".

Yet as bizarre as this stuff is, it is apparently headed for Recommendation.
Why?  Because it has the blessing of both Microsoft and Netscape, and that's
apparently 95% of what's needed.  If George W. Bush and Al Gore decide child
abuse is a Good Thing ... well, by golly, I guess it must be.  If you feel
strongly about this, say so on the www-style mailing list (see
<http://www.w3.org/Mail/Lists.html>). H?kon Lie has spoken against it, so have a
few others; it's probably already a "done deal", but even so, it's right to
speak out against inevitable absurdities.

> Obese standards are invalid.

Indeed.


/Jelks


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



From jelks at jelks.nu  Sun Nov 21 06:16:19 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:23 2004
Subject: Feeling good about SML
In-Reply-To: <003601bf3349$ad5bd890$5df96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <NBBBICMNIPCICMKJECCBAEAADCAA.jelks@jelks.nu>

Rick Jelliffe wrote:

> But why this endless "not invented here" desire to reinvent XML. It is
> still a mystery too me.  The complication in the XML world is not XML
> 1.0, but namespaces 

Amen!

> (which means that an element names may mean
> different things in different contexts) and class-based schemas (which
> can mean that even within a namespace a name may mean different things
> depending on context).  Anyone who thought DTDs were hard may be in for
> a shock unless we are careful!

Isn't that water already under the bridge?


/Jelks


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



From jelks at jelks.nu  Sun Nov 21 09:03:09 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:23 2004
Subject: facts, conclusions, and exhortations re XML (long)
In-Reply-To: <199911210111.TAA00461@bruno.techno.com>
Message-ID: <NBBBICMNIPCICMKJECCBMEABDCAA.jelks@jelks.nu>

Steven R. Newcomb wrote:

> I ran across more evidence of Microsoft's anticompetitive behavior
> recently.  Most of you probably already knew about it.  XPath, as
> implemented by Microsoft, provides access to the first node of any
> nodelist as the zeroeth node (the node in the list that is addressed
> by an array index value of 0), while the relevant W3C draft requires
> it to be the first (index value of 1) node.

"XPath as implemented by Microsoft", do you have a link or two about this?  A
lot of folks I know are drooling for MS to implement the new XPath and XSLT
Recommendations, yet you're saying not only have they already done it, but
they've deliberately sabotaged it!  ?

> One way to pay taxes is to be forced to buy new software every few
> years.  But what if the services that the taxes are supposed to pay
> for are suboptimal, or distributed unfairly or unwisely?  What if the
> tax collectors line their own pockets with obscene amounts of money
> and power, at the worldwide public's involuntary expense?

Government -- the real monopoly -- *forces* you to pay taxes.  You have *no
other choice*.  Try not paying them.  I don't know if your children will be
buying MS software or services in 50 years; I guarantee you their Government
will be taking (by force) "its share" ...

>   "Information owners and users of the world, unite!  Insist that the
>    software and systems you buy are built to guarantee that the value
>    of your information cannot be diminished merely by technological
>    change, or by the caprices of would-be world dominators (in Redmond
>    or elsewhere), or by the fortunes of your software providers.
>    Quite literally, you have nothing to lose but the product
>    differentiation barriers that jeopardize your economic security and
>    progress."

Lord.  I'd have to go with the Evil Capitalist Monopolistic Empire if the
alternative is based on rhetoric that gave us USSRs and Tiananmen Squares.

[There are *some* at MS who get it, especially with regard to XML.  (That
doesn't include the last FrontPage, Office, or ASP teams :).  It's a constantly
changing company -- if you want to "reform" it, give it competition and "vote"
with your dollars.  Microsoft listens to competition; too bad the previous
competition was Netscape.]


/Jelks




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



From gtn at ebt.com  Sun Nov 21 13:34:14 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:23 2004
Subject: External Entities A Field Guide (was RE: Feeler for SML (SimpleMarkup Language))
In-Reply-To: <38356CB8.1899D3AF@isogen.com>
Message-ID: <000401bf3424$8dbbdef0$f7d45dc7@ebt.com>

> This is my statement and I stand by it. In my experience the at-scale
> use of external parsed entities for re-use has only ever led to pain.

Fine. Let's agree to disagree, because my experience building at-scale
systems that *rely* on external entities has been positive (though
again, perhaps it's more that the use was largely hidden and not
so not under direct control of the people involved).


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



From martind at netfolder.com  Sun Nov 21 15:33:03 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:23 2004
Subject: FW: About template. part 2
Message-ID: <NBBBJPGDLPIHJGEHAKBACECPEHAA.martind@netfolder.com>

Hi Don,

Don said:
-----------
Looks like we are heading toward same goal via different mental
track.  The word 'document' invokes too many preconceived notions
to be used in this context, I believe.  XML stream is more like it.
XML stream that changes its structure over time requires dynamic
schema with ability to redefine, augment, remove schema fragments.

Implementation wise, this is rather simple.  Have client dynamically
download schema fragment-specific handlers.  Security is no problem
since they are restricted to operations on the stream itself.  Java
is a perfect fit for this.

Didier reply:
-------------
Frankly I do not how to call this. Let's then look at it from a pragmatic
point of view and a "market observation" point of view (O yeah,
phenomenology again :-).

a) "market observation" point of view:
--------------------------------------
It seems that, in the last year, the tendency to use HTTP as a transport
mechanism and URLs as function call mechanism has gained some adepts. Take,
for example, the latest e-commerce specs from commerce.net (ref:
http://www.eco.commerce.net). An important trait of this latest spec is the
usage of URLs as function calls and XML as the result of these function
calls. The URL is divided with the following parts:
              <protocol>://<domain>/<function call>?<parameters>
The returned gizmo (replace gizmo with the term you find most appropriate)
is an XML text which does not contain a DTD and thus, no validation is
necessarily expected from the receiver.

We have here a classical request and response function. For Java people, it
is like doing a Java function call (having parameters) and obtain, as
result, a string containing an XML text.

If you take, this time, the Microsoft SQL technological preview. You can
observe that the same kind of mechanism is in place. a) a URL is used as a
function call with a SQL request as parameter. The URL is thus formatted as
follow:
            <protocol://<domain>/<virtual directory name>?sql=<SQL request>
The returned gizmo is also an XML text. Again for Java guys, its like doing
a function call with a SQL request as parameter and the function returns an
XML text contained in a string.

Oracle, on its side, supports URLs as function calls which refers to
specific XML gizmos containing SQL requests to be applied on a relational
database (not necessarily with the new SQL where the request may be applied
on an object view instead of a relational view). IN this last case, what is
very interesting though, is their notion of XML template. A whole XML gizmo
may be sent with a HTTP post to the server and this latter will return an
XML gizmo as request fulfillment.

I can go, on and on with some more examples, but three are probably enough.

>From these examples, we can deduct
1 - that HTTP is used as a transport mechanism. More particularly, two HTTP
verbs are mainly used: a) GET and b) POST. In both cases, and because of the
HTTP protocol requirements, a gizmo is returned and this gizmo has a MIME
type. In our case, the MIME type is "text/xml" (or an equivalent MIME type).
2 - The URL is used as a kind of function call. As we would find in any
function call having a sound constitution, it comes with parameters if there
is some needs for parameters.
3 - Basically what is returned is a model and more particularly a
hierarchical model encoded in an XML gizmo.

b) pragmatic point of view:
---------------------------
A workflow model as found in most workflow structures (ref:
http://www.wfmc.org/) is organized around a workflow engine. In a workflow,
a process is a succession of activities. The workflow engine has the
responsibility to "flow" the worked item from activity to activity. There is
different design choices that may be implemented for "task routing" like,
for instance, a) encoding the "route" in the item (which may be an XML
gizmo) b) keep this information internally hidden in the workflow engine. If
(a) is chosen and if XML is the format used to encode the gizmo that will be
moved from "task station" to "task station" then, each "task station" is
"carrying on" an activity to "transform" the XML gizmo or to extract
information (for purists, simply data :-) from the XML gizmo.

At each process stage, the XML gizmo may me stored and retrieved with the
HTTP protocol (respectively with the POST and GET verbs). Or may be  flowed
through the process with a mix of synchronous (i.e. HTTP) and asynchronous
(i.e. SMTP) transportation mechanisms.

The context being set, let's now get to the point.

If we take, for instance, biztalk, even if I have a fuzzy vision of what a
biztalk server will do, it remains that potentially a biztalk gizmo (i.e. an
XML gizmo) may contain "routing" information. Thus, the "routing" info is
stored in the document instead of being hidden in the workflow server. The
biztalk document or more particularly the "body" part may change in time as
each "task station" does its job. Thus, the biztak framework may be seen as
an envelope containing an XML gizmo that may change over time as "task
station" agent carry on their activity on this routed XML gizmo.

We can then see a biztalk envelope as the same kind of gizmo used in the
telecom industry to carry or transport data from one place to an other. For
instance, an IP packet can be contained in an Ethernet packet.

    	-----------------------------------------------------------------
	|Ethernet packet									|
	|											|
	|	-------------------------------------------------------	|
	|	| IP packet								|	|
	|	|									|	|
	|	-------------------------------------------------------	|
	|											|
	-------------------------------------------------------------------

I hope the mail won't scrap my pieces of arts :-))

As well, an e-commerce XML gizmo may be contained in a biztalk envelope.
This latter contains the "route" for the contained e-business XML gizmo.

    	-----------------------------------------------------------------
	|Biztalk envelope									|
	|											|
	|	-------------------------------------------------------	|
	|	| E-business XML gizmo						|	|
	|	|									|	|
	|	-------------------------------------------------------	|
	|											|
	-------------------------------------------------------------------

I picked here biztalk, not because I am a Microsoft fan, but simply because
its out there and documented and probably will have a certain influence in
the community (I agree Len, the balance of power is not yet in the hands of
the knowledge but still in the hands of the capital :-) ref: The post
industrial society by Daniel Bell).

Thus, we have here a potential network of HTTP servers, used to route
particular XML gizmos from task station to task stations where activities
carried on this XML gizmo conduct to its transformation (i.e. the biztalk
body) or get data extracted from the xml Gizmo.

Lesson learned from this:
------------------------------------
1 - These kind of HTTP servers are then special kind of XML servers used to
route XML gizmos. Other kind of XML task station carry on acivity on the XML
gizmo.
2 - Some XML elements are used as "routing" information containers for "task
stations". Thus, the XML gizmo is a particular assembly composed of one part
used for transportation and "task routing", an other part being the
meaningful gizmo transported. Both parts may change in time. For instance,
the routing part may loose all previous "routing" locations as it moves
through the process. The other XML gizmo part may change as "task agents"
modify it along the way.
3 - The basic interaction between all the agents is conducted through HTTP
basic verbs POST and GET and thus is based on a simple request response
system. However, other transportation means may be used as for instance the
mail (SMTP protocol) to move th XML gizmo from a routing server to an other
and to and from this server and a task station. Thus, HTTP is not the only
mean of transportation but seems to be an important one.
4 - The contained gizmo may include a special PI for rendition and then
could be first, extracted from the transport XML gizmo and then rendered
with any XML browsers equipped with the proper rendition engine (for example
CSS or XSLT-HTML/CSS). This may be required as the "task agent" may be a
human being having to do task where visual (or should I said here sensorial)
examination leads to an action taken on or from this rendered XML gizmo.

So, if what is transported by HTTP or SMTP is a document or not, I do not
know, so let's call it an XML gizmo :-)

Simple Saturday morning reflections
Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 21 17:07:09 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:23 2004
Subject: Feeling good about SML
Message-ID: <3.0.32.19991121085857.01426160@pop.intergate.ca>

At 09:13 AM 11/19/99 -0500, Michael Champion wrote:
>That's precisely what Don Park is doing -- trying to get us to figure out
>what in XML is of "fundamental significance", and what is merely residue of
>the SGML legacy and impedes understanding, implementing, processing, and
>using XML in the real world.

Hmm... in the part of the real world where I live, there seem relatively
few impediments to the understanding, implementation, processing, and use
of XML.  Just going on the evidence of what I see. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 21 17:07:14 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:23 2004
Subject: XML Memory Requirements (was Re: Feeling good about SML)
Message-ID: <3.0.32.19991121084811.01473850@pop.intergate.ca>

At 07:28 PM 11/18/99 -0500, Tyler Baker wrote:
>Other Java XML parsers I have seen use a similiar approach
>except that the store the character bitmap in the class file itself which has the unfortunate
>problem of bloating the size of your class file immensely, and slowing down startup time
>because the stupid way Java deals with constant arrays of primitive types in classes is that
>it generates instructions for initializing each section of the array to the desired value
>instead of just having a stream of bytes that are read into the array one by one.

Yes, indeed, Java is megastupid this way.  The workaround I ended up with was
smashing all the numbers together into a big String, which still makes a
large-ish class file (but you're going to have to transmit that data
one way or another anyhow), but only one run-time push statement.  

To use the data, there are a variety of tricks available dependig what it
is you've mashed into the String; in my case String.toCharArray() did
the trick. -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 21 18:28:44 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:23 2004
Subject: FW: About template. part 2
References: <NBBBJPGDLPIHJGEHAKBACECPEHAA.martind@netfolder.com>
Message-ID: <383838E3.53B4@hiwaay.net>

Didier PH Martin wrote:
> 
> I picked here biztalk, not because I am a Microsoft fan, but simply because
> its out there and documented and probably will have a certain influence in
> the community (I agree Len, the balance of power is not yet in the hands of
> the knowledge but still in the hands of the capital :-) ref: The post
> industrial society by Daniel Bell).

I might but right now, reading the XML Schema will consume the fun 
reading time.   Paying gigs and all that.  The process descriptions 
you provide show that you are thinking the application through 
in the environment in which it is used and with which it must 
interface.  Que bueno. 

SML can be a subset of XML and still be XML just as XML is a subset of 
SGML and is still SGML.  Call any application language what you like.  
Nothing prevents a device-specific application language from being
written 
and fielded.   Write a spec which restricts the features you need.  The 
odd bit is because you have SGML Declarations, you might be better off 
making it a sibling of XML, not a child.  Of course, that means someone 
has to be sharp enough with markup to work that out.  Just carving up 
XML may not be the best thing to do and if done, someone who starts 
from the parent language and works their way into the subset may 
get a better system with more legitimacy not that that matters among 
us bastards.

Capital rules if economic success is required to field a system.  Some 
systems, eg, Linux, don't need commercial success first.  They need 
trained users (computer scientists).  After that, then when it becomes 
something to sell to the mortals, the RedHats of the world capitalize 
and become the new Microsoft's, just as capitalized, just as entrenhed.

If the system is pre-stigmatized, then the success is not one of
technical application but of 
convincing sufficient numbers that you have a better solution which
despite 
the wart on its tail will enable them to succeed either by making new 
opportunities or by seizing them from those who cannot or will not 
defend their own.  Often, to do that, you must convince people who
cannot 
understand the technical so rely on the simplistic.  SML is a simplistic
approach.
  
It will work but it may or may not sell.  That depends on who supports
it, 
so if the Nokia's of the world have the clout, they can make that
happen.  The question 
the information designer asks is what processes governed by what
policies 
will the data objects be used in?   The systems engineering approach to
this 
is straightforward and non-political. 

Selling is always political.  All politics are local.  What happens 
at the boundaries of locales?  Interfaces.    It is and has been 
noted, the difficulty of hypertext language design:  what is the 
practical difference between the implementation of a hyperlink and the 
implementation of a function?  None really.  So, goTo, goSub, goDo, 
and do well.  If that simple approach proves as HTML 2.0 did, not 
to have the power to sustain the applications it targets, next 
year, it won't be so simple.  I suspect the SMLers have not yet, 
as the HTMLers did not, consider the production issues.

I am agnostic about SML.  There may be reasons for re-invention, and 
more for specification, but none for counter-revolution other than 
a name and a name for those that name it.  XML showed the way by 
taking an ISO standard, re-inventing that, changing the name, and 
creating a W3C specification.  So far, so good.  Good engineering needs 
documented requirements (and by that, not those sophomoric lists that 
start with "must be easy"; that is an annotation about the user, not the 
system), but real tangible descriptions of the target system, the 
system boundaries, the environment (interfaces) and so forth.  
I suspect that by the time the SMLer works their way through 
all of that, the cellphone/palmpilot competitors will already have 
something working.  Running code and all that...

The Internet gets messier every day.  Such a market.  Oy vey.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Sun Nov 21 19:35:59 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:23 2004
Subject: Embrase.. Expand.. Extint..
Message-ID: <NBBBJPGDLPIHJGEHAKBAMEDAEHAA.martind@netfolder.com>

Hi,

You have probably noticed that two new spots appeared recently in the XML
world radar. Did you?
- E-speak
- Biztalk

These two universes have even an early SDK or Jumpstart kit.

Let's first examine Biztalk (I am still studying E-speak)

What is Biztalk?
-----------------
Biztalk is basically a message system. It is a XML based message system.
Several tools are provided in the Jumpstart to create VB objects from
X-Schema. In this sense, Biztalk may be perceived as a middleware like CORBA
or DCOM. Why? The IDL gets replaced with X-Schema and tools are provided to
create COM objects from X-Schemas. The marshalling format between the
objects is the XML format. An XML document named a biztalk document
encapsulate an XML fragment. The XML fragment is the message content, the
biztalk document the message's container. Microsoft defined the envelope,
the container, you define the contained fragment.

What is important to notice here?
---------------------------------
Two facets:
a) A message based middleware using SMTP, HTTP, XML and X-schema as ground
base. So far so good...
b) A subtle movement from an internet based messaging system to a Microsoft
based messaging system.

WHY?
Is this the conspirator theory again :-) No, just a simple analysis of facts
and implications of these facts in the market place.

A) What is the actual notion of an internet message?
----------------------------------------------------
The actual notion of an internet message is simply a text beginning with a
set of headers (ref: RFC 822)

This format is quite simple and is the base for both the internet mail
system and the HTTP system. For both, a message begins with a set of headers
like below:

<attribute>: <value>

Example:
--------------------------------
content-type: text/xml
from: martind@netfolder.com
to: xml-dev@ic.ac.uk

....this is the message body....
---------------------------------

Thus,  both HTTP messages and SMTP messages are formatted the same way. Only
the property set or the set of headers differ. There is a set of headers
particular to HTTP and set of headers particular to SMTP. Some are common
for both

The message's content is distinguished from the headers by a line feed
between the headers and the message body (as shown above).

B) What is a biztalk message?
-----------------------------

An XML document that could contain a "route" element. This latter specify
the "to" and "from" and other information about the document "routing".
On the windows platform, Biztalk messages will be processed by a Biztalk
server acting as a middleware tool to "route" the Biztalk documents. If both
ends are equipped with a Windows machine and more preferably with a Win2000
platform, the following scenario may occur.

a) the biztalk message is received by the recipient biztalk server
b) The message body is matched to a message handler. The matching process is
based on the name space Identifier.
c) if a matching message handler is found, this latter is instantiated and
given the biztalk message for processing. In fact, its interface member
named ProcessMessage is called and given the received biztalk message as
parameter.
d) The message handler does its job.

The message handler is a piece of code such as a Visual Basic piece of code.
The message content is encapsulated with a generated piece of code from an
X-Schema. Thus, the x-schema can be seen as an object interface definition
language and the generated piece of code as an objects like a CORBA or DCOM
object. The Biztalk message can then be seen as the marshaled format between
the objects.

C) What can be the consequences?
---------------------------------
Obviously, on windows, a rich set of tools will be available to process
biztalk messages.
a) Object creation generator from X-Schema
b) biztalk server
It will be, most probably be less expensive to have a windows platform on
both the client and server side.
But...
We moved from an internet based messaging system to a Microsoft based
messaging system. The major implication is that the message is now more
easily controled by Microsoft.

Why then the message properties are not encoded in RFC 822 format? The
answer may be that the biztalk server may choose the most appropriate
transport mechanism. For instance, that certain messages types are accepted
on a particular recipient only through SMTP. That encoding the message
information in XML provide some independence from the transport layer.

Is this flying? I do not know. But what I do know is:
A message server could be based on the internet messaging format. Here is
the possible scenario:

the sender prepares a simple RFC 822 encoded message as follow:

content-type: text/xml
from: martind@netfolder.com
to: xml-dev@ic.ac.uk
... imagine here other headers that can provide more info.....

<my-e-business xmlns=" a URI here ">
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl" media="screen"?>
... my e-business content....
</my-e-business>

The message headers could contain enough information for both a HTTP or SMTP
server. Or the message headers can contain a X-something header (X-something
header are proprietary headers - but an IETF workgroup or group of
developers can add new headers for middleware).

To provide transport independence, an IETF workgroup (or a group of
developers like for instance, this present group) could define a new header
like for instance "recipient" or "x-recipient". This latter having a URN
value. The URN could be resolved into one or several URLs like for instance
the URL of a HTTP server or the URL of a SMTP server. This implies that a
message like below:

sender: urn:DUNS:364824948
recipient: urn:DUNS:12635948

<my-e-business xmlns=" a URI here ">
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl" media="screen"?>
... my e-business content....
</my-e-business>

is transformed into the message below if the middleware server gets from its
database that the sender prefer that its business partners responds to it
with e-mail and that its business partner prefer an asynchronous transport
protocol like e-mail. Thus, the message is transformed for transportation by
the middleware server into:

content-type: text/xml
from: martind@netfolder.com
to: xml-dev@ic.ac.uk

<my-e-business xmlns=" a URI here ">
<?xml-stylesheet href="mystylesheet.xsl" type="text/xsl" media="screen"?>
... my e-business content....
</my-e-business>

We just separated the document from the message. The message is still an
internet message based on RFC 822 and extensions. New headers could be
proposed through the IETF mechanism. As you know, IETF requires that at
least two different implementations should be in place for standard
approval. It means that, contrary to the biztalk project where only a
Microsoft server is sufficient, to be called an IETF standard, Microsoft
would have to find an other partner who would do also an implementation. Do
you think it is easy for a monopoly to convince an other player in the
industry to do an implementation knowing that Microsoft is doing one also
and that this partner knows about what are the advantages of competing
against a monopoly :-)))

So , now the implications:
Moving from an internet based messaging system to a biztalk based messaging
system: Is it gaining more freedom from a monopoly?

Where are our interests?

Now, who is interested to work on a document (created from the industry, not
proposed by a monopoly) to specify new internet messaging headers to
transport XML documents. The goal is to have the messaging system
independent of the transport layer (synchronous=HTTP,
asynchronous=SMTP/POP3/IMAP4). This middleware knowing the recipient
prefered transport preferences can translate some message headers into the
right one for transportation. Like for instance changing the "x-recipient"
for the "to: xml-dev@ic.ac.uk" header because the recipient prefers the
email as a comunication mechanism.

Hoops...The workflow server has something to say...what? He just said that
part of the solution he was searching is present in an internet messaging
based system. Why? because the message sender can include its style sheet so
that its contained XML message could be rendered if there is a need to do so
at the receiving point. The scope is resolved with the actual XSLT specs.
The scope is its document.

If nobody is interested to discuss the issue or at least to help create this
document, then let's the monopoly decide for us :-))
Any volunteers ? (of course the final document is co-signed by everybody who
participated to the discussion and the elaboration of the document).

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Sun Nov 21 20:34:05 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:23 2004
Subject: A Joke?
Message-ID: <NBBBJPGDLPIHJGEHAKBAMEDBEHAA.martind@netfolder.com>

Hi,

In my last post "embrace...expand...extinct" (and I discovered I made a typo
in the title :-) I ended with a Joke, The joke to unite against the
monopoly. I have no intention to fight against a monopoly :-) Today, David
would need more than a small piece of rock to kill Goliath.

However I should say that the Biztalk idea is not a bad idea. What I would
like to see thought is the same kind of routing mechanism as an A
Apache add-on. In fact, an Apache server receiving something like a biztalk
message through a post message could do the appropriate "routing". Also, in
my list of wish dreams is to see some developers start to work on defining a
Biztalk kind of messaging system instead of being sad about history or about
the power of the giants. In fact, in one of those dreams I envisioned
something like:


			------------------------------
client ---------> |     transaction server	| ------------> HTTP server
			|	using HTTP protocol	|
			--------------------------------------------> SMTP
server ------------->POP3---------> client

The transaction server receives an XML message through a POST. The message
is stored as a transaction. Based on the XML message received it then relay
the transaction to the right server. If something gets wrong, it can try
through a different transport or try it later.

What are you doing Didier? David is not allowed to dream. Its November, you
should be sad and think of the past not the future. And the future is
decided by the giants not the Davids :-))

Go it?

Never under estimate the power of the capital.
Faith can move mountains - if "lost faith" goto previous line.

Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From wchang at nist.gov  Sun Nov 21 21:31:40 1999
From: wchang at nist.gov (Wo Chang, x3439)
Date: Mon Jun  7 17:17:23 2004
Subject: msxsl error
Message-ID: <199911212129.QAA20696@ion.antd.nist.gov>

Hi,

I once used the msxsl to generate html pages from
an xml input document via xsl style sheet, but now
when I try to run same program, it gives me the
following error message:

   Error parsing document 'abc.xml'
   Exception: hr= 0x80070057
   
The only different between before and now is I'm
running Win98 (with IE5) now and before was Win95 
(with IE4).

Can anyone help me to identify the cause of the
problem?  Was it due to the software expiration?
Or, do I need a newer version of msxsl for Win98/NT?
If I do, where can I get a newer version?  I kind 
of search the www.microsoft.com/xml but couldn't
find them.

Any helps would be greatly appreciated.

--Wo Chang


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



From ch at XMLwriter.net  Sun Nov 21 23:08:00 1999
From: ch at XMLwriter.net (Chris Howard)
Date: Mon Jun  7 17:17:23 2004
Subject: ANNOUNCEMENT: XMLwriter 1.0 is Released
Message-ID: <001801bf3475$19e1f540$0100a9c0@boost>

Fellow XML Junkies,

Wattle Software is pleased to announce the release of XMLwriter 1.0 - a
major upgrade from our previous beta version. A special thanks to all of the
beta testers and people who sent us their feedback in response to our very
popular "wishlist".

You can download the new version from http://XMLwriter.net/download.html for
Windows 9x/NT/2000.

One of the major new features included in XMLwriter 1.0 is User Tools. User
Tools allows you to run external applications from within XMLwriter. No
longer are you limited to IE5's support of the XML standards! For example,
using User Tools, you can use IBM's XML4C parser to validate your XML
documents, or LotusXSL to convert your XML documents using XSL. Each User
Tool you configure is displayed on the Tools menu and toolbar for quick
access. You can optionally capture the output generated by User Tools within
XMLwriter's Tool View, or in a new document. There are a lot of XML tools
out there, so we've created a User Tools help page on our website to get you
started (see http://XMLwriter.net/user_tools/user_tools.html )

Other new features include:

-External file modification detection
-Syntax colouring of new file extensions
-Customisable file filters
-Line-wrapping option when loading files
-Automatic validation on open/save
-Create and save new document templates
-Optionally create backups on save
and more (see http://XMLwriter.net/features.html )

For a list of bugs fixed from XMLwriter 1.0 Beta see
http://XMLwriter.net/fixes_1_0_beta.html .

We hope you enjoy this release version and we look forward to hearing from
you! Please send your feedback to yoursay@XMLwriter.net.

Kind Regards,

-------------------------------
Chris Howard
Wattle Software
Email: ch@XMLwriter.net
Web:   http://XMLwriter.net/
-------------------------------


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



From clark.evans at manhattanproject.com  Mon Nov 22 01:06:37 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:24 2004
Subject: facts, conclusions, and exhortations re XML (long)
In-Reply-To: <NBBBICMNIPCICMKJECCBMEABDCAA.jelks@jelks.nu>
Message-ID: <Pine.LNX.4.10.9911210649580.1995-100000@cauchy.clarkevans.com>


On Sun, 21 Nov 1999, Jelks Cabaniss wrote:
> Government -- the real monopoly -- *forces* you to pay taxes. 

It is "taxation without representation" that led the 
founders of the United States to fight for independence. 
Microsoft makes no efforts to be representative, so
comparing Microsoft to a democratic government is
logically flawed. 

> You have *no other choice*.  

Wrong.  You can leave the country  --  about as much choice 
as you have in a corporate environment with regard to which
operating system you will use.   Ballance is required -- both 
capitalism and democracy are bad in their extreme.

Therefore, we are here on this list to give firm support, 
resonable critique, and committment to a governmental-like 
organization, the W3C, which exists to define the rules by 
which our software programs (read business processes) will 
cooperate in a competitive business environment.  Any threat 
to undermine these rules must be taken seriously, and this
I believe is the meat of Steve's argument.

> [Microsoft is a constantly changing company -- if you want 
> to "reform" it,  give it competition and "vote" with your dollars.  
> Microsoft listens to competition; too bad the previous 
> competition was Netscape.

You obviously have not read Judge Jackson's findings of fact.

Standards, in this case the W3C's XML standards are what 
will enable this reform by putting competitors on equal footing.
Right now, if your implementation disagrees with Microsoft's
implementation -- you are wrong.  Independent standards hope 
to change this... if they do not, then other, more drastic 
measures, like Open Source software are our only hope for a 
fair environment for vigorous competition.

That being said, I hope that Microsoft does not have a policy 
to subvert XML.  However, given the Judge's findings, I am not 
going to dismiss the possibility of a less-than-honorable Microsoft.

Best Wishes,

Clark


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



From martind at netfolder.com  Mon Nov 22 01:43:10 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:24 2004
Subject: Embrase.. Expand.. Extint..
In-Reply-To: <001501bf3471$af25c4a0$0b00a8c0@grissom>
Message-ID: <NBBBJPGDLPIHJGEHAKBAOEDEEHAA.martind@netfolder.com>

Hi Ken,

Ken said:
Three "new spots" -- the most recent is Oracle eXchange.

Didier reply:
Thanks for mentionning the third spot in the XML world radar

Ken said:
The expert panel discussion at XML One was taped and it will shortly be
available at www.technetcast.com. The panel included Bill Smith of OASIS
(xml.org) and Dan Rogers of Microsoft (biztalk.org). Bill Smith talked about
OASIS's efforts to embrace and extend XML, particularly to enable more small
and medium-sized organizations to participate in XML-based e-commerce.

Didier reply:
I look forward listening to this.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Ravisekhar_Kopparthi at apex.soft.net  Mon Nov 22 03:47:26 1999
From: Ravisekhar_Kopparthi at apex.soft.net (Ravisekhar_Kopparthi@apex.soft.net)
Date: Mon Jun  7 17:17:24 2004
Subject: No subject
Message-ID: <65256831.0014535C.01@apxblr2.apex.soft.net>



Dear all,
I need Microsoft xml Parser in Java for my project.
Iam unable to get the parser which has the com package with the classes
like Document,Element,ParseException etc.,
through any website including the Microsoft one.
Hence I request you to kindly pass on the zip file containing the above
MSXML parser with those classes if you have it.
I found your email addresses through the web.
Eagerly expecting immediate reply.
Thank you.
Yours sincerely,
K.Ravisekhar
email: Ravisekhar_Kopparthi@apex.soft.net



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



From gtn at ebt.com  Mon Nov 22 04:50:13 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:24 2004
Subject: Feeling good about SML
In-Reply-To: <000201bf3081$bf4444e0$099918d1@docuverse1>
Message-ID: <000e01bf34a4$8ef6c0c0$f3d45dc7@ebt.com>

> 1. SML shall be easier to learn than XML
> 
> Ideally, one should be able to learn the ins and outs of SML
> COMPLETELY within 30 minutes.  Amount of time spent is not
> important but it can be used to indirectly measure the level of
> required attention span, mental model complexity, amount of
> details one must remember, etc.

I think that making the syntax trivial to learn is the least
of the problem. The real issues lie in applicability and
in the problems XML is being applied to. Even today it doesn't
require a lot of work to apply XML to a problem... but then
again, it takes a fair amount of skill to apply XML to the
problem *meaningfully*.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov 22 04:53:53 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:24 2004
Subject: Feeling good about SML
References: <3.0.32.19991121085857.01426160@pop.intergate.ca>
Message-ID: <00c201bf34a4$d2764370$efd18dce@WORKGROUP>


----- Original Message -----
From: Tim Bray <tbray@textuality.com>
To: Michael Champion <Mike.Champion@softwareag-usa.com>; XML Dev
<xml-dev@ic.ac.uk>
Sent: Sunday, November 21, 1999 12:08 PM
Subject: Re: Feeling good about SML


> At 09:13 AM 11/19/99 -0500, Michael Champion wrote:
> >That's precisely what Don Park is doing -- trying to get us to figure out
> >what in XML is of "fundamental significance", and what is merely residue
of
> >the SGML legacy and impedes understanding, implementing, processing, and
> >using XML in the real world.
>
> Hmm... in the part of the real world where I live, there seem relatively
> few impediments to the understanding, implementation, processing, and use
> of XML.  Just going on the evidence of what I see. -Tim

But Tim, you quite literally (co-)wrote the book on XML ... and one of the
first parsers, and I'm sure a ton of XML applications.  No one would expect
*you* , or anyone with SGML expertise, for that matter, to have any trouble
understanding, implementing, or using it.  But how about the rest of the
real world?

>From the evidence that I see here and other XML and W3C mailing lists, a
disproportionate number of the misunderstandings, implementation problems,
and practical problems we talk about would be moot if Don Park had his way
;~)

Without DTDs, we wouldn't have to argue about whether they are useless or
not.  Without external parsed entities, we wouldn't have to argue about
whether they are evil or not.  Without CDATA sections, we wouldn't have to
argue about whether they are mere syntactic sugar or whether they have some
semantic content. Without PIs, we wouldn't argue about whether the XML
declaration is a PI or not ... Without Notations, nobody would ask what they
are and what they're good for.

Obviously all these things have their uses and users who depend on them.
Don's not asking those people to stop using them (or arguing about them). He
is challenging us to figure out if -- in the light of real-world
experience -- they have proved their worth as *fundamentally necessary*
components of 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Mon Nov 22 05:17:42 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:24 2004
Subject: Embrase.. Expand.. Extint..
References: <NBBBJPGDLPIHJGEHAKBAMEDAEHAA.martind@netfolder.com>
Message-ID: <004e01bf34a9$34b5a4a0$0b00a8c0@grissom>

Didier PH Martin said <martind@netfolder.com>

> You have probably noticed that two new spots appeared recently in the XML
> world radar. Did you?
> - E-speak
> - Biztalk

Three "new spots" -- the most recent is Oracle eXchange.

> On the windows platform, Biztalk messages will be processed by a Biztalk
> server acting as a middleware tool to "route" the Biztalk documents. If
both
> ends are equipped with a Windows machine

(Some of this was discussed two weeks ago at the XML One conference in Santa
Clara.)

1. A "Windows machine" is not required. The architect of a major middleware
product told me at the conference that modifying his server to process
BizTalk messages was trivial.

2. Microsoft is obviously going to produce a toolkit for Win 2000 and Visual
Basic, but Linux and Perl are a fact of life -- so there is also a Perl
toolkit.

The expert panel discussion at XML One was taped and it will shortly be
available at www.technetcast.com. The panel included Bill Smith of OASIS
(xml.org) and Dan Rogers of Microsoft (biztalk.org). Bill Smith talked about
OASIS's efforts to embrace and extend XML, particularly to enable more small
and medium-sized organizations to participate in XML-based e-commerce.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 06:10:13 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:24 2004
Subject: Feeling good about SML
References: <3.0.32.19991121085857.01426160@pop.intergate.ca> <00c201bf34a4$d2764370$efd18dce@WORKGROUP>
Message-ID: <3838DE2D.2BC1646D@pacbell.net>

Michael Champion wrote:
> 
> Without DTDs, we wouldn't have to argue about whether they are useless or
> not.  Without external parsed entities, we wouldn't have to argue about
> whether they are evil or not.  Without CDATA sections, we wouldn't have to
> argue about whether they are mere syntactic sugar or whether they have some
> semantic content. Without PIs, we wouldn't argue about whether the XML
> declaration is a PI or not ... Without Notations, nobody would ask what they
> are and what they're good for.

Of course, the pragmatists among us could say "just use the darn
tool and stop arguing, so there won't be any arguments" ... ;-)

 
> Obviously all these things have their uses and users who depend on them.
> Don's not asking those people to stop using them (or arguing about them). He
> is challenging us to figure out if -- in the light of real-world
> experience -- they have proved their worth as *fundamentally necessary*
> components of XML.

As folk have pointed out, pointy brackets aren't "fundamentally necessary"
and LISP S-Expressions are _at least_ as powerful ... with a much richer
and more powerful set of programming systems and traditions behind them.

So a "fundamentally necessary" argument is not at all convincing to me.
Almost anything can be removed in the right situation.


On the other hand ... just removing <!DOCTYPE ...> declarations and
everything associated with them would be a _simplifying_ move, and in
many cases simplification is good.  The question then becomes exactly
which of the N schema systems merits the World Domination 2K prize.

And we all know schemas are never going to lead to any arguments, and
every one of the mechanisms proposed in every one of the schema languages
to date is in the "fundamentally necessary" group of features, yes?  ;-)

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 06:27:17 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:24 2004
Subject: Feeling good about SML
In-Reply-To: <3.0.32.19991121085857.01426160@pop.intergate.ca>
Message-ID: <000501bf34b2$efdb1a40$099918d1@docuverse1>

>Hmm... in the part of the real world where I live, there seem
>relatively few impediments to the understanding, implementation,
>processing, and use of XML.  Just going on the evidence of what I see. -Tim

Maybe we live in different worlds.  Based on experience,
companies starting to adopt XML typically hire XML consultants
to design their systems.  Most of them are not confident that
they know all the details of XML and thus are compelled to use
outside help.  The problem is that once the consultant is done,
the companies do not have the expertise to maintain and extend
the design.  This is quite different from the way HTML has been
adopted and used.  People started using HTML immediately.

Also, there is a definite problem with the way XML is being
extended.  Because of the 'sacred main document structure'
constraint, extensions are being forced rely on awkward
features.  XML stylesheet standard used PI, DT4DTD uses
notations, XML namespace standard uses special attributes.

Frankly, I wouldn't be surprised to see people start using
comments for some new standard.  Removing the comment feature
will force the people to treat comment as first-class information.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abisheks at india.hp.com  Mon Nov 22 07:27:49 1999
From: abisheks at india.hp.com (Abhishek Srivastava)
Date: Mon Jun  7 17:17:24 2004
Subject: Elements or Attributes
Message-ID: <006a01bf34ba$f98493c0$252f0a0f@india.hp.com>

Hi,

I have the following XML doc:

<screen>
<height> 480 </height>
<width>  640 </width>
</screen>

Another way of creating the same document would be:
 <screen height="480" width="640"> </screen>

Is there any difference in the two approaches in terms of
1. Memory Consumption
2. Speed of Building the DOM
3. Speed of recursively searching the DOM say for value of "width".

How can I determine which approach is appropriate for my application.
Can anyone help me in choosing between the two. 
I am using XML4C2_3_1 on HP-UX and Win NT.

regards,
Abhishek.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _/               Abhishek Srivastava
   _/                Hewlett Packard ISO       
  _/_/_/   _/_/_/    -------------------   
 _/    /   _/   _/     (Work)   +91-80-2251554 x1190
_/  _/   _/_/_/      (Ip)     15.10.47.37            
        _/           (Url)    http://sites.netscape.net/abhishes/index.html                        
       _/            
                     Work like you don't need the money.
                     Dance like no one is watching.
                     And love like you've never been hurt.
                     --Mark Twain                       
                     
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991122/da7f6ab0/attachment.htm
From paul at prescod.net  Mon Nov 22 07:39:53 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:24 2004
Subject: SGML, XML and SML
References: <001601bf32ec$2d1b55a0$099918d1@docuverse1>
Message-ID: <3837C904.A2DE9E69@prescod.net>

Don Park wrote:
> 
> I don't understand what 'this' is.  Are you suggesting that SML should
> be abandoned in favor of S-expressions or are you saying that S-expressions
> didn't fly so SML won't either?

Here's what I'm saying:

 * XML has lots of stuff that most of these applications do NOT need.
 * XML *lacks* some important things that these applications DO need,
the most important being a structured property syntax

A language with neither of these flaws could be designed in a week and a
parser for it could be written in half a day in any language. Writing
such a parser would be not that much more work than strapping in an XML
parser -- actually it would be less if there is no parser that meets
your needs. Such a language could be DOM-compatible, XPath-compatible,
XSLT compatible and so forth if it was designed to be.

Therefore, why force unminimized angle brackets to do something that
they are weak at? Just to prove the point that every data type in the
universe can have a single syntax?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 07:39:49 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:24 2004
Subject: Parser compliance
References: <3.0.32.19991117093112.01aad530@pop.intergate.ca>
Message-ID: <3837C5FC.ED77E924@prescod.net>

Tim Bray wrote:
> 
> I have often wondered where this myth arose that validating against a DTD
> will tell you, in useful real-world terms, "what's wrong with your XML".

What's a DTD for, if not to tell you in useful, real-world terms what's
wrong with your XML? The question isn't whether it tell you everything
that's wrong, the question is whether it tells you an important subset
of everything?

One could just as easily complain that database schemas do not always
prevent bad data getting into a database and static type checking
doesn't prevent bad algorithms.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Bart: Dad, do I really have to brush my teeth?
Homer: No, but at least wash your mouth out with soda.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 08:26:09 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun  7 17:17:24 2004
Subject: SGML, XML and SML
In-Reply-To: <3837C904.A2DE9E69@prescod.net>
Message-ID: <Pine.GHP.4.21.9911220811350.8349-100000@mail.ilrt.bris.ac.uk>

On Sun, 21 Nov 1999, Paul Prescod wrote:

> Don Park wrote:
> > 
> > I don't understand what 'this' is.  Are you suggesting that SML should
> > be abandoned in favor of S-expressions or are you saying that S-expressions
> > didn't fly so SML won't either?
> 
> Here's what I'm saying:
> 
>  * XML has lots of stuff that most of these applications do NOT need.
>  * XML *lacks* some important things that these applications DO need,
> the most important being a structured property syntax
> 
> A language with neither of these flaws could be designed in a week and a
> parser for it could be written in half a day in any language. Writing
> such a parser would be not that much more work than strapping in an XML
> parser -- actually it would be less if there is no parser that meets
> your needs. Such a language could be DOM-compatible, XPath-compatible,
> XSLT compatible and so forth if it was designed to be.
> 
> Therefore, why force unminimized angle brackets to do something that
> they are weak at? Just to prove the point that every data type in the
> universe can have a single syntax?

Hmm... reminds me... The original PICS-Next-Generation (aka PICS
2) proposal, the precursor to RDF, used an s-expression based
syntax. This was of course dropped in favour of an XML syntax.

Excerpt from http://www.w3.org/TR/NOTE-pics-ng-metadata

	[...]
	5.1. S-Expression Syntax

	The syntax of PICS-NG is greatly simplified from that of PICS version
	1.1. Basically PICS-NG syntax in a straightforward manner consists of
	s-expressions where additional restrictions are placed on the types of
	values of certain elements of s-expression structures. PICS-NG parsing
	is a multi-step process. Parsing of a single label happens as follows:

    	1.A simple s-expression parser is used to parse (and verify) the
	overall syntactic structure (given below in the form of a BNF
	definition).
       This is the only step necessary if one is not interested in any
	semantic interpretation of the label (if the data is only passed
	through, if the
       	parsing agent has no knowledge of the schemata used, etc.). 
    	2.Information from each of the schemata of a label is used to verify
	that attribute values have legal values. 
	    3.Any other information from the schemata is used for semantic
		interpretation of the label. 

	This syntax has been chosen because it is simple to parse, provides a
	straightforward correspondence between the model and the syntactic form
	of the data, is brief (good "over the wire" -characteristics), and (by
	not being too verbose) is easy for humans to read and write. A BNF
	definition
	of the overall syntactic structure is given below (despite that fact
	that BNF rather poorly lends itself to describing s-expressions)
	[...]


What goes around comes around! The RDF Interest Group [1] is currently
discussing alternate syntaxes for RDF in XML. Sounds like we're being
told we'd be better off returning to PICS-NGesque s-expressions. I doubt
that this would be well received... ;-)

Dan



[1] http://www.w3.org/RDF/Interest/


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 08:49:21 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:24 2004
Subject: SGML, XML and SML
In-Reply-To: <Pine.GHP.4.21.9911220811350.8349-100000@mail.ilrt.bris.ac.
 uk>
References: <3837C904.A2DE9E69@prescod.net>
Message-ID: <3.0.6.32.19991122083203.009e67d0@gpo.iol.ie>

[Dan Brickley]
>
>What goes around comes around! The RDF Interest Group [1] is currently
>discussing alternate syntaxes for RDF in XML. Sounds like we're being
>told we'd be better off returning to PICS-NGesque s-expressions.

Not so AFAIK. I would be interested to read the XML-DEV posts that
have lead you to this conclusion. Can you point me at them?

regards,



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 09:14:27 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun  7 17:17:25 2004
Subject: SGML, XML and SML
In-Reply-To: <3.0.6.32.19991122083203.009e67d0@gpo.iol.ie>
Message-ID: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk>

On Mon, 22 Nov 1999, Sean McGrath wrote:

> [Dan Brickley]
> >
> >What goes around comes around! The RDF Interest Group [1] is currently
> >discussing alternate syntaxes for RDF in XML. Sounds like we're being
> >told we'd be better off returning to PICS-NGesque s-expressions.
> 
> Not so AFAIK. I would be interested to read the XML-DEV posts that
> have lead you to this conclusion. Can you point me at them?

I was being slightly tongue-in-cheek, but the combination of Paul
Prescod's msg (which I replied to) and previous SML advocacy seemed to
be heading in this direction. In other words, that for many
data-oriented applications, XML's document-oriented heritage makes it
sometimes challenging to use. I'm far from convinced that a return to
s-expressions, or the creation of a trivial subset (SML), would be
useful right now. There are enough X** specifications and applications
around already to make it a nightmare for non XML-obsessed developers
trying to figure out how the various piecese of the puzzle
inter-relate. Inventing a new subset syntax would make it even hard to
present a coherent picture...

Dan




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 09:41:48 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:25 2004
Subject: SGML, XML and SML
In-Reply-To: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.
 uk>
References: <3.0.6.32.19991122083203.009e67d0@gpo.iol.ie>
Message-ID: <3.0.6.32.19991122092429.009e4100@gpo.iol.ie>

>> [Dan Brickley]
>> >
>> >What goes around comes around! The RDF Interest Group [1] is currently
>> >discussing alternate syntaxes for RDF in XML. Sounds like we're being
>> >told we'd be better off returning to PICS-NGesque s-expressions.
>> [Sean McGrath]
>> Not so AFAIK. I would be interested to read the XML-DEV posts that
>> have lead you to this conclusion. Can you point me at them?
>
> [Dan Brickley]
>I was being slightly tongue-in-cheek, but the combination of Paul
>Prescod's msg (which I replied to) and previous SML advocacy seemed to
>be heading in this direction. In other words, that for many
>data-oriented applications, XML's document-oriented heritage makes it
>sometimes challenging to use. I'm far from convinced that a return to
>s-expressions, or the creation of a trivial subset (SML), would be
>useful right now. 

OK. I see where you are coming from. My position is this:-
1) SML must be allowed to be born so that it can either
die of natural causes or flourish. 
2) SML must be a subset (application profile) of XML.
3) To quote Henry Thompson (I think) "We should stop worrying
and learn to love xLink". By which I mean, a lot of
the thunkery that goes on with entities, notations,
PIs etc. might disappear in a puff of logic if only
we had xLink. The combination of SML with a rich
object linking mechanism is and idea that I feel
deserves its 15 minutes of flame:-)

regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Ravisekhar_Kopparthi at apex.soft.net  Mon Nov 22 09:56:17 1999
From: Ravisekhar_Kopparthi at apex.soft.net (Ravisekhar_Kopparthi@apex.soft.net)
Date: Mon Jun  7 17:17:25 2004
Subject: MSXML paser
Message-ID: <65256831.00365360.00@apxblr2.apex.soft.net>



Hai,
I am working on a e-commerce project which requires xml to be used as a
middle tier.
Iam fresh to xml.
I know how to write dtd and a well formed xml document.
I have Internet Explorer 5.0  with me. I came across some article which
says IE5.0 has inbuilt xml parser.
So I wrote a simple xml document and opened it in IE5.0 I could see a tree
structure displayed.
But I want to extract the parsed character data out of the xml.
I don't know how to proceed.
If any one has Microsoft xml parser  containing com package with
Document,Element,ElementFactory,ParseException
classes please kindly mail me.
Iam in an immense need of that.
Thank you
Ravisekhar_Kopparthi@apex.soft.net



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



From sasha at moldat.co.il  Mon Nov 22 10:16:43 1999
From: sasha at moldat.co.il (Sasha (Moldat))
Date: Mon Jun  7 17:17:25 2004
Subject: unsubscribe
Message-ID: <006301bf34d2$8813d1c0$0300a8c0@sasha>

unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991122/389bcd8e/attachment.htm
From bosak at boethius.eng.sun.com  Mon Nov 22 10:15:39 1999
From: bosak at boethius.eng.sun.com (Jon Bosak)
Date: Mon Jun  7 17:17:25 2004
Subject: Do SGML and XML co-exist?
In-Reply-To: <E11pgtx-0006vB-00@tomatin.cc.ic.ac.uk>
	(owner-xml-dev-digest@ic.ac.uk)
Message-ID: <199911221015.CAA09972@boethius.eng.sun.com>

[Len Bullard:]

| No.  It [generic markup] started earlier than that.  SGML hypertext
| systems with stylesheets were already on the market prior to 1990.
| Some systems had been being worked since ISO8879 was a draft.  Long
| before XML, the SGML community had debated it on comp-text-sgml.  The
| problem was not complexity but the inanity of the HTML working group.
| Hytime and DSSSL, yes, these are complex, but to be blunt, put all of
| the XML specs together, throw them on the floor, and see how loud a
| thump they make.
|  
| Beware facile demonstrations of simplicity.  Bosak knows it was 
| a show piece and that once the work was underway, it would 
| fatten out.  It didn't matter.

Len is no doubt referring to the gimmick of tossing a copy of the
30-page XML spec into the first rows of an SGML audience without
killing anyone.  Credit for this wonderful piece of theater belongs to
Tim Bray, not me.

[Tim Bray:]

| It is to Jon Bosak's immense credit that he (like many of us) not only
| saw the need for simplification but (unlike anyone else) went and
| hounded the W3C until it became less trouble for them to give him his
| committee than to keep on saying SGML was irrelevant.

That is the most accurate description of my actual contribution that
has been written by anyone.

[Betty Harvey:]

| Personally, I give credit to Yuri Rubinsky, President of SoftQuad
| until his untimely death, to the birth of XML.

Me too.  He was obviously heading in this direction with SoftQuad
Panorama and his efforts to engage the Web community with "SGML on the
Web".  I would never have taken up the torch if Yuri had lived; I
would simply have kept following him.  I have felt throughout the XML
effort that I have just been trying to realize Yuri's vision.

| It does distress me that now that XML has become popular that the
| pioneers are forgotten, especially Yuri.  He was a man who impacted
| not only the web but people positively.  He was a real visionary.  I
| also believe he would be really pleased about the current XML efforts.

In general, I don't worry that the pioneers will be forgetten in the
end.  Eventually the historians will catch up with this and we shall
all just become footnotes in someone's doctoral dissertation.  Credit
will be given where it's due.

But I agree that it would be hard to understand Yuri's impact without
having seen him in action.

Jon

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



From sasha at moldat.co.il  Mon Nov 22 10:17:55 1999
From: sasha at moldat.co.il (Sasha (Moldat))
Date: Mon Jun  7 17:17:25 2004
Subject: unsubscribe
Message-ID: <008801bf34d2$bbd5a2e0$0300a8c0@sasha>

unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991122/73228e06/attachment.htm
From murata.makoto at fujixerox.co.jp  Mon Nov 22 10:19:30 1999
From: murata.makoto at fujixerox.co.jp (MURATA Makoto)
Date: Mon Jun  7 17:17:25 2004
Subject: UTF-8 vs UTF-16...? (Was: Feeling good about SML)
Message-ID: <199911221021.AA03316@archlute.fujixerox.co.jp>

Tim Bray writes:
>In terms of actual usability, there's effectively no difference between
>UTF-16 and UTF-8.  UTF-16 seems to be an easier sell in Japan for reasons
>that I've not fully understood.

Many Japanese prefer UTF-8 to UTF-16, but I don't.

I prefer UTF-16, since XML documents in legacy encodings never parse 
as UTF-16 and those in UTF-16 never parse as legacy encodings.  On the 
other hand, they may parse as UTF-8 and lead to corrupted outputs.

As Tim knows very well, UTF-16 has a number of problems about byte 
ordering.  On the other hand, UTF-8 it not free from such problems.
UTF-8 from Microsoft appears to begin with the zero-width non-breaking 
space always ;-(

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Patrice.Bonhomme at loria.fr  Mon Nov 22 10:34:03 1999
From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme)
Date: Mon Jun  7 17:17:25 2004
Subject: CGI + perl + XML ?
Message-ID: <199911221019.LAA03369@chimay.loria.fr>


Hi,

I am looking for a generic CGI script written in perl that takes all fields 
from an HTML form and generates an XML document.

Thanks,
Pat.

-- 
  ==============================================================
   bonhomme@loria.fr      Tel : 03 83 59 30 52 / 06 11 34 03 85
   http://www.loria.fr/~bonhomme                 Office : B.228
  --------------------------------------------------------------
   * Serveur Silfide  : http://www.loria.fr/projets/Silfide
  ==============================================================



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



From rgl at decisionsoft.com  Mon Nov 22 10:56:33 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:25 2004
Subject: CGI + perl + XML ?
In-Reply-To: <199911221019.LAA03369@chimay.loria.fr>
Message-ID: <Pine.LNX.4.10.9911221049510.21742-100000@localhost.localdomain>

On Mon, 22 Nov 1999, Patrice Bonhomme wrote:

> I am looking for a generic CGI script written in perl that takes all fields 
> from an HTML form and generates an XML document.

Rather than using perl, you could use X-Tract (our free XML Script
processor) server-side (behind Apache or IIS), which will talk to CGI
quite easily - all information entered in the form will be available as if
X-Tract were processing a document with a top-level <CGI></CGI> element,
and each name-value pair represented as <Name>Value</Name>. See Tutorial 9
of the documentation on http://www.xmlscript.org/ for further details.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


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



From martind at netfolder.com  Mon Nov 22 11:53:44 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:25 2004
Subject: Embrase.. Expand.. Extint..
In-Reply-To: <001501bf3471$af25c4a0$0b00a8c0@grissom>
Message-ID: <NBBBJPGDLPIHJGEHAKBAMEDLEHAA.martind@netfolder.com>

Hi Ken,

Ken said:
Three "new spots" -- the most recent is Oracle eXchange.

Didier request:
The Oracle site http://www.oracleexchange.com/ is not too verbose on the
technologies used except that somewhere it is said that it will use EDI, XML
and internet related technologies. Do you have more info?

Question: What is the difference between OracleExchange and vertical portals
like Chemdex except the fact that OracleExchange do not seem to have any
specialty. Do you know if Oracle Exchangwe will work with Biztalk messages?

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abcoates at TheOffice.net  Mon Nov 22 12:58:13 1999
From: abcoates at TheOffice.net (Anthony B. Coates)
Date: Mon Jun  7 17:17:25 2004
Subject: If SAX == lex, then what == yacc?
Message-ID: <199911221306.AAA05146@mail.internetezy.com.au>

A thought that struck me (and probably struck many of you before me) is that
the event stream from a SAX parser is much like the token stream from a lexical
analyser, like 'lex'.  This made me wonder what the equivalent to 'yacc' would
be in this picture; an application that help you construct the logic for dealing
with event streams.  Is there such an application?  I cannot immediately think
of one.  XSLT has some of the features you would expect of such an application,
but because it is designed to be state-free, it isn't the same as a
state-sensitive application like 'yacc'.

Has anyone any suggestions as to which applications may fill this void?  Am I
missing something really obvious?  Please don't pass on your dislike of
yacc/bison, if any (I prefer JavaCC myself, but that is another story).

	Cheers,
			Tony.

** Anthony B. Coates    >> mailto:abcoates@TheOffice.net <<
** Software Engineer (Java).  This is a 100% Pure Java e-mail.
** AJUG National Secretary (see http://www.ajug.org.au/)

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



From Andy.Bradbury at syntegra.bt.co.uk  Mon Nov 22 13:09:15 1999
From: Andy.Bradbury at syntegra.bt.co.uk (Andy.Bradbury@syntegra.bt.co.uk)
Date: Mon Jun  7 17:17:25 2004
Subject: facts, conclusions, and exhortations re XML (short)
Message-ID: <65AF45D5E535D2118AFB0008C7FA23180C3E54@FL-EXCHANGE-03>



Steve Newcomb wrote:

>The only weapon we have against Microsoft's
>abuse of the public's confidence is the truth.
>The truth is also the only weapon that's needed.
>Let us wield that weapon vigorously.  If you feel
>that you can't tell the truth about Microsoft's
>deliberate undermining of the goals of the XML
>community without incurring financial or other costs,
>I'd ask you to consider the following questions:

etc.

Before WWI, E.M. Forster (Room with a View, A Passage to India, etc.) wrote
what seems to me to be a remarkably prophetic parable on the cosequences of
monopolistic technology run rampant, a short story called: The Machine
Stops.
I'd suggest that regardless of which particular conglomerate, organisation
or cartel has tried, is trying or will try to seize the reins, the basic
concepts within the story are something we need to be taking very seriously
*right now*.

Regards

Andy B.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 13:23:44 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:25 2004
Subject: Feeling good about SML
In-Reply-To: "Michael Champion"'s message of "Sun, 21 Nov 1999 23:48:28 -0500"
References: <3.0.32.19991121085857.01426160@pop.intergate.ca> <00c201bf34a4$d2764370$efd18dce@WORKGROUP>
Message-ID: <m3hfieoe2y.fsf@localhost.localdomain>

"Michael Champion" <Mike.Champion@softwareag-usa.com> writes:

> > Hmm... in the part of the real world where I live, there seem relatively
> > few impediments to the understanding, implementation, processing, and use
> > of XML.  Just going on the evidence of what I see. -Tim
> 
> But Tim, you quite literally (co-)wrote the book on XML ... and one of the
> first parsers, and I'm sure a ton of XML applications.  No one would expect
> *you* , or anyone with SGML expertise, for that matter, to have any trouble
> understanding, implementing, or using it.  But how about the rest of the
> real world?

Oops!  I'm pretty sure Tim was talking about the thousands of people
he's met as customers, business associates, and audiences over the
past few years, not about himself.

I would be very happy to have the opportunity to meet a quarter as
much of the Real World as Tim has, if only I could find a way to do it
without travelling.


All the best,


David

p.s. The little bit of the real world I've met wants running software
that does interesting and useful things -- standards and specs are
just a means to that end.  Just parsing XML (or SML) is neither
interesting nor useful: it's a tiny (even with SGML!) library function 
hidden in a much larger application.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From matthew at praxis.cz  Mon Nov 22 13:29:03 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:25 2004
Subject: Why validate? (was Re: Parser compliance)
References: <Pine.GSO.3.96.991118111535.13911K-100000@grind>
Message-ID: <383944D2.E83D33AB@praxis.cz>

Robin,

Here's at least one voice of absolute 100% agreement. "Running code" and
prose are patently not the only ways to express application semantics.
The current XML Schema draft already hints at things to come; if I can
state that a given element has content of type "positive integer" and
must be between 10 and 20, I am already expressing semantics that would
otherwise have to be implemented in procedural code. This and (IMHO) a
lot more can be expressed a lot more clearly and productively in a
declarative manner using schemas than in mucky "running code". It may
not be a sure thing, but it's certainly plausible that future XML
applications will be a combination of relatively low-level procedural
code and relatively high-level descriptive code (in the form of
schemas). There is no precedent for this, DTDs or other, which makes the
whole business quite exciting to think about. (And if anyone knows of
cases where people have tried approaches like this, in the SGML/XML
field or elsewhere, I'm VERY interested. Please let me know.)

Matthew

Robin Cover wrote:
> 
> While agreeing that SGML/XML DTD syntax is of limited value
> in supporting "validation," I think David Megginson and
> Tim Bray have somewhat short-changed the notion of
> declarative, constraint-based (ontologic/relational) semantics
> and corresponding (generalized, middle-tier) machine
> processing of constraint-based semantics within the "markup"
> framework.  I'm speaking of how things could be, not how
> they were (ISO 8879:1986) and are (XML 1.0) given
> the expressiveness of DTDs.
<rest snipped>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 13:31:27 1999
From: nicmila at vscht.cz (Miloslav Nic)
Date: Mon Jun  7 17:17:25 2004
Subject: New Zvon tutorial - XPath tutorial
Message-ID: <38394569.C843948@vscht.cz>

I have just published a new Zvon tutorial at:
http://zvon.vscht.cz/ZvonHTML/Zvon/zvonTutorials_en.html

XPaths are just wonderful. I really hope that they will be used as much
as possible so there is my little contribution to their propagation.

-- 
***************************************************************
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  
****************************************************************
Support free information exchange: http://zvon.vscht.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rgl at decisionsoft.com  Mon Nov 22 13:50:36 1999
From: rgl at decisionsoft.com (Richard Lanyon)
Date: Mon Jun  7 17:17:25 2004
Subject: Why validate? (was Re: Parser compliance)
In-Reply-To: <383944D2.E83D33AB@praxis.cz>
Message-ID: <Pine.LNX.4.10.9911221345160.22005-100000@localhost.localdomain>

On Mon, 22 Nov 1999, Matthew Gertner wrote:

> It may
> not be a sure thing, but it's certainly plausible that future XML
> applications will be a combination of relatively low-level procedural
> code and relatively high-level descriptive code (in the form of
> schemas). There is no precedent for this, DTDs or other, which makes the
> whole business quite exciting to think about.

It also makes it slightly worrying - the fact that it's new means that
it's less likely to catch on, IMHO. Many, many people are familiar with
writing basic (or even BASIC) procedural code, which makes me think that
whatever catches on in the field of small-scale webpage XML scripting is
likely to be procedural. While I can see why a more declarative style
might be appropriate for a large-scale project, these sorts of reasons are
not the reasons why HTML caught on in the first place.

-- 
Richard Lanyon (Software Engineer) |     "The medium is the message"
XML Script development,            |             - Marshall McLuhan
DecisionSoft Ltd.                  |


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 13:47:24 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:25 2004
Subject: What do XML consultants actually do?
In-Reply-To: "Don Park"'s message of "Sun, 21 Nov 1999 22:26:57 -0800"
References: <000501bf34b2$efdb1a40$099918d1@docuverse1>
Message-ID: <m3emdiod0u.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> Maybe we live in different worlds.  Based on experience,
> companies starting to adopt XML typically hire XML consultants
> to design their systems.  Most of them are not confident that
> they know all the details of XML and thus are compelled to use
> outside help.

God!  If I were paid to help people figure out XML syntax, I would be
way, way, way, WAY overpaid.  What companies hire consultants for is
to help them understand how to exchange and process information: 90%
of the complexity comes from the nature of the information they're
trying to model and the business environment in which they work, 9.9%
of the complexity comes from finding, learning, and integrating the
software components, and perhaps the remaining 0.1% has something to
do with the syntax of the markup layer (but probably not).

If we switched to LaTeX, or S-expressions, or structured RTF, the only
difference would be in the availability of off-the-shelf software
components and training materials.  The hard part is figuring out how
to manage the open exchange of news, music data, maintenance
information, magazine archives, or what-have-you, not learning where
to stick the angle brackets.

I have billed many thousands of hours on XML projects to large and
small companies, and I have never once sat down and taught XML syntax,
nor can I remember if I have ever (in an XML project) said or heard
the phrases "DOCTYPE", "XML comment", "processing instruction",
"notation", or "unparsed entity".

I fully expect the techs with my customers to (a) learn basic XML
syntax on their own by spending a couple of hours with a tutorial or
(b) simply ignore it and trust the libraries, depending on their
needs.  If they're totally lost, I give the the URL of Robin Cover's
XML Web Page [1] and tell them to get back in touch in a day or two.

> Frankly, I wouldn't be surprised to see people start using
> comments for some new standard.  Removing the comment feature
> will force the people to treat comment as first-class information.

With luck, the Infoset will help avoid this problem by specifying that 
comments are not a required part of the Infoset.


All the best, and good luck with SML,


David

[1] http://www.oasis-open.org/cover/

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 14:21:27 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:26 2004
Subject: If SAX == lex, then what == yacc?
References: <199911221306.AAA05146@mail.internetezy.com.au>
Message-ID: <00c401bf34f4$c41ea330$eb020a0a@bowstreet.com>

> A thought that struck me (and probably struck many of you before me) is
that
> the event stream from a SAX parser is much like the token stream from a
lexical
> analyser, like 'lex'.  This made me wonder what the equivalent to 'yacc'
would
> be in this picture; an application that help you construct the logic for
dealing
> with event streams.  Is there such an application?

FOP (and I suspect a lot of XML applications) takes SAX events and builds a
tree structure out of objects that belong to a class depending on the
element type or attribute. This tree building is handled through a largely
generic builder and the mappings from element and attribute name to class
name are provided to the builder at run-time. In the case of attributes (and
perhaps eventually elements), the actual classes themselves are generated
from XML schemas.

I don't know if it is the equivalent of "yacc" but it seems to be a fairly
generic way of dealing with event streams that still allows
application-specific tailoring.

James Tauber


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



From ypatil at kingston.hummingbird.com  Mon Nov 22 14:19:32 1999
From: ypatil at kingston.hummingbird.com (Yogita Patil)
Date: Mon Jun  7 17:17:26 2004
Subject: MSXML paser
References: <65256831.00365360.00@apxblr2.apex.soft.net>
Message-ID: <0b2501bf34f4$9e81e240$1a02060a@andyne.com>

Try using this for some info. I think it has what you need.
http://msdn.microsoft.com/xml/c-frame.htm?942761851213#/xml/demos/default.as
p

Yogita.
----- Original Message -----
From: <Ravisekhar_Kopparthi@apex.soft.net>
To: <xml-dev@ic.ac.uk>
Sent: Tuesday, July 20, 1999 5:29 AM
Subject: MSXML paser


>
>
> Hai,
> I am working on a e-commerce project which requires xml to be used as a
> middle tier.
> Iam fresh to xml.
> I know how to write dtd and a well formed xml document.
> I have Internet Explorer 5.0  with me. I came across some article which
> says IE5.0 has inbuilt xml parser.
> So I wrote a simple xml document and opened it in IE5.0 I could see a tree
> structure displayed.
> But I want to extract the parsed character data out of the xml.
> I don't know how to proceed.
> If any one has Microsoft xml parser  containing com package with
> Document,Element,ElementFactory,ParseException
> classes please kindly mail me.
> Iam in an immense need of that.
> Thank you
> Ravisekhar_Kopparthi@apex.soft.net
>
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 14:28:47 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:26 2004
Subject: Why validate? (was Re: Parser compliance)
References: <Pine.GSO.3.96.991118111535.13911K-100000@grind> <383944D2.E83D33AB@praxis.cz>
Message-ID: <00d901bf34f5$e1e052f0$eb020a0a@bowstreet.com>

> It may
> not be a sure thing, but it's certainly plausible that future XML
> applications will be a combination of relatively low-level procedural
> code and relatively high-level descriptive code (in the form of
> schemas).

As I wrote in response to Anthony Coates on "If SAX == lex...", FOP
generates application classes on the basis of a schema-like description of
attributes. I'm moving towards actually using the W3C schema language, but
with extensions that enable me to say things like "in the absence of an
explicit value for this attribute, compute a value on the basis of that
attribute". Although it is an implementation issue, I'm actually just using
XSLT to go from high-level descriptive schema-like XML to Java source.

Amongst other things, I'm excited about the opportunities this provides for
literate programming. While I'm working on this specifically for FOP, most
of what I'm working on in generic. My plan is for it to be possible to take
the XML description of properties and generate (via XSLT): Java source,
human readable documentation and a normal schema.

James Tauber



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



From martind at netfolder.com  Mon Nov 22 14:58:00 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:26 2004
Subject: What is a document?
Message-ID: <NBBBJPGDLPIHJGEHAKBACEDPEHAA.martind@netfolder.com>

Hi,

Continuing the reflection on biztalk like XML formats, a question occurred
in my mind: In a biztalk like message, what is the document?

Hypothesis 1
--------------
The biztalk message is the document. Your content included in the biztalk
message is a fragment.

Hypothesis 2:
-------------
The content is the document. The biztalk element is an envelope.

Problem:
--------
We want to provide the message rendition for human consumption. Thus, the
biztalk message is set for automated agents on both sides. However, we want
to provide a style sheet with the message so that if a human wants to take a
look at it, it can be rendered with style ;-)

Hypothesis 1 - reasoning:
---------------------------
If the biztalk message is the document, then the style sheet has to be
included at the biztalk message level. But the real content and the part
control by the sender is the fragment contained in the biztalk message. So,
the biztalk processor may do the following if the sender included a style
sheet in the fragment.
a) remove the style sheet PI from the fragment
b) import the fragment style sheet in its own style sheet.
the two style sheet are merged

Hypothesis 2 - reasoning:
--------------------------
No it does not work without some processing from the biztalk engine because
the scope of action for a style sheet is the whole XML document, not a
fragment. Thus, the biztalk message is the document, not the contained
fragment.

Conclusion:
-----------
According to the actual state of the art, only Hypothesis 1 will fly. If we
think of rendition, we have to think of document. If we think about
document, then a biztalk message is also a document. The content (your
message) is only a fragment. In the XML world there is no actual standard
notions of
a) envelope
b) multiple document embedding for transport (each embedded fragment being a
separate entity interpreted by different agents)

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at mitretek.org  Mon Nov 22 14:55:36 1999
From: tpassin at mitretek.org (Thomas B. Passin)
Date: Mon Jun  7 17:17:26 2004
Subject: facts, conclusions, and exhortations re XML (short)
Message-ID: <007f01bf34f9$94ee27c0$38a3f1ce@ls-.mitretek.org>

Nice to hear from someone else who has read this little gem.  Amazingly
modern-sounding, wasn't it?

Tom Passin

From: Andy.Bradbury@syntegra.bt.co.uk <Andy.Bradbury@syntegra.bt.co.uk>
>Before WWI, E.M. Forster (Room with a View, A Passage to India, etc.)
wrote
>what seems to me to be a remarkably prophetic parable on the
cosequences of
>monopolistic technology run rampant, a short story called: The Machine
>Stops.
>I'd suggest that regardless of which particular conglomerate,
organisation
>or cartel has tried, is trying or will try to seize the reins, the
basic
>concepts within the story are something we need to be taking very
seriously
>*right now*.
>



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 15:05:11 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:17:26 2004
Subject: psgml XML problem
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F278147@MDYNYCMSX1>

I'm setting up Redhat 6.2 on a new machine and having a problem. Trying to
parse an XML file using PSGML with Xemacs, ^c^p on a document beginning with
the following

 <!DOCTYPE mydoc [ <!ELEMENT mydoc (#PCDATA)> ]>

gives me this message, with the cursor sitting on the space after DOCTYPE
above:

  Uppercase keyword expected.; at: mydoc [

The same happened with v 2.28 and v 2.48 of psgml. This is under RedHat 6.2;
it worked fine under S.u.S.E 5 and I'm using the same .emacs file that I did
there. Also, psgml has no problem with an SGML file. Has anyone had this
problem before and figured it out? 

thanks,

Bob DuCharme          www.snee.com/bob           <bob@  
snee.com>  "The elements be kind to thee, and make thy
spirits all of comfort!" Anthony and Cleopatra, III ii

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 15:11:04 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:17:26 2004
Subject: What is a document?
Message-ID: <8DCB90532FF7D211B34400805FD48853A94A71@SENMAIL3>

I would say the content is the document. The BizTalk framework will simply
allow content to be transported in a message format, telling processers
which understand the relevent tags (ie. the BizTalk environment) what to do
with the content - where to route it etc...

I suppose it's much like posting a letter, where your content is hidden
within the envelope and the envelope simply has instructions (ie. Airmail,
Address etc..) on how the envelope should be handled? - Not sure about
postcards though?

That's a bit simple to explain the entire framework, but some BizTalk
processing would have to be done, although there is no reason why you should
not be able to directly extract the XML content within the <message> tags?

Steven


Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Didier PH Martin [SMTP:martind@netfolder.com]
> Sent:	22 November 1999 13:52
> To:	'XML Dev'
> Subject:	What is a document?
> 
> Hi,
> 
> Continuing the reflection on biztalk like XML formats, a question occurred
> in my mind: In a biztalk like message, what is the document?
> 
> Hypothesis 1
> --------------
> The biztalk message is the document. Your content included in the biztalk
> message is a fragment.
> 
> Hypothesis 2:
> -------------
> The content is the document. The biztalk element is an envelope.
> 
> Problem:
> --------
> We want to provide the message rendition for human consumption. Thus, the
> biztalk message is set for automated agents on both sides. However, we
> want
> to provide a style sheet with the message so that if a human wants to take
> a
> look at it, it can be rendered with style ;-)
> 
> Hypothesis 1 - reasoning:
> ---------------------------
> If the biztalk message is the document, then the style sheet has to be
> included at the biztalk message level. But the real content and the part
> control by the sender is the fragment contained in the biztalk message.
> So,
> the biztalk processor may do the following if the sender included a style
> sheet in the fragment.
> a) remove the style sheet PI from the fragment
> b) import the fragment style sheet in its own style sheet.
> the two style sheet are merged
> 
> Hypothesis 2 - reasoning:
> --------------------------
> No it does not work without some processing from the biztalk engine
> because
> the scope of action for a style sheet is the whole XML document, not a
> fragment. Thus, the biztalk message is the document, not the contained
> fragment.
> 
> Conclusion:
> -----------
> According to the actual state of the art, only Hypothesis 1 will fly. If
> we
> think of rendition, we have to think of document. If we think about
> document, then a biztalk message is also a document. The content (your
> message) is only a fragment. In the XML world there is no actual standard
> notions of
> a) envelope
> b) multiple document embedding for transport (each embedded fragment being
> a
> separate entity interpreted by different agents)
> 
> Cheers
> Didier PH Martin
> mailto:martind@netfolder.com
> http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 15:27:53 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:26 2004
Subject: SGML, XML and SML
Message-ID: <3.0.32.19991122072523.0145b100@pop.intergate.ca>

At 09:24 AM 11/22/99 +0000, Sean McGrath wrote:
>OK. I see where you are coming from. My position is this:-
>1) SML must be allowed to be born so that it can either
>die of natural causes or flourish. 
>2) SML must be a subset (application profile) of XML.

And SML must not claim, explicitly or implicitly, to "be XML".  SML
may or may not be a good idea.  It would certainly be a bad idea
to give lazy vendors a trapdoor so they could run around announcing
"we support XML" while also rejecting XML 1.0 documents that don't
happen to conform to this subset.  Also bad to give arrogant 
I-don't-mess-with-other-peoples-code junior programmers an excuse to 
write their own partial parsers for fun thus wasting everyone's time and 
money.

XML ain't perfect, but at this point it has pretty darn good 
interoperability.  Messing that up would be a blunder of historic
proportions.

I would urge W3C to defend its copyright on the name "XML" quite
vigorously in this scenario.

>3) To quote Henry Thompson (I think) "We should stop worrying
>and learn to love xLink". 

Speaking as the long-suffering co-chair of XLink, I predict that we're
finally going to get that job done in the immediate future.  And I think
Henry (if it was him) has a point. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dhunter at Mobility.com  Mon Nov 22 15:27:11 1999
From: dhunter at Mobility.com (Hunter, David)
Date: Mon Jun  7 17:17:26 2004
Subject: Feeling good about SML
Message-ID: <805C62F55FFAD1118D0800805FBB428D02BC00E0@cc20exch2.mobility.com>

From: Don Park [mailto:donpark@docuverse.com]
Sent: Monday, November 22, 1999 1:27 AM
> 
> >Hmm... in the part of the real world where I live, there seem
> >relatively few impediments to the understanding, implementation,
> >processing, and use of XML.  Just going on the evidence of 
> what I see. -Tim
> 
> Maybe we live in different worlds.  Based on experience,
> companies starting to adopt XML typically hire XML consultants
> to design their systems.  Most of them are not confident that
> they know all the details of XML and thus are compelled to use
> outside help.  The problem is that once the consultant is done,
> the companies do not have the expertise to maintain and extend
> the design.  This is quite different from the way HTML has been
> adopted and used.  People started using HTML immediately.

I would argue that this isn't a problem with XML, but with the scenario
you've just described, and probably mostly because of the way XML was hyped,
vs. the way HTML was hyped.  ("It can do anything" for XML, which sounds
more complex, vs. "Anyone can do it" for HTML.)

I may not be a Tim Bray, but I had no problems using XML in my applications
either.  Most of my XML usage has been exactly what people are describing
for SML; no PIs, external entities, DTDs/Schemas, etc.  Much of it is just
simple elements and text.  The fact that I'm using an XML parser, instead of
an SML parser, has never hindered me.  The fact that I can call my markup
language "XML", instead of something else, has only benefited me.

For this reason, I still follow the "if you don't need it, JUST DON'T USE
IT" philosophy on this debate.  It's true, I'm a consultant, not a
Joe-Clueless-User.  But I don't think XML was designed for Joe-Clueless-User
- it was designed to exchange meaningful information, most of the time from
software to software.  (If SML is targeted toward Joe-C-U, I don't think it
will fly in that direction either.  The type of information Joey wants to
convey is more effectively done in HTML/XHTML.)

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



From clark.evans at manhattanproject.com  Mon Nov 22 15:21:16 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:26 2004
Subject: facts, conclusions, and exhortations re XML (long)
In-Reply-To: <Pine.LNX.3.96.991120205655.29374A-100000@www.falconwing.com>
Message-ID: <Pine.LNX.4.10.9911212204510.5424-100000@cauchy.clarkevans.com>

On Sat, 20 Nov 1999, Sean Chen wrote:
> I believe the the implementation talked about here is XQL, a precursor to
> XPath.  Nowhere has Microsoft claimed to implement XPath yet, AFAIK.  In
> fact, according to Microsoft, they are refusing to implement XSLT or XPath
> until the final recommendation, which has only just happened this week.

Sean,

Surely Microsoft (the well-funded pre-release alpha software giant) has:

1. Announced (several months in advance) about their upcoming Explorer,
   detailing how it will closely follow the W3C's recommendatoins.

2. Have already provided (on their alpha site) a XSL engine compilant
   with at least one of the previous working drafts.   IBM, Sun, and
   Oracle have done this several times.  Hmm.  From my memory even 
   individuals like Keith Visco and Michael Kay have done this.  

3. Have been providing valueable comments (as a W3C member) based on
   their implementation knowledge to make sure that the standard 
   will work well for their development partners.

4. Alreay have (on their alpha site) a pre-release download of
   a stylesheet engine compliant with the October working 
   draft -- so that their development community can be assured 
   that they are developing stylesheets which will work on many 
   other platforms; not just Microsoft's products.

Best, 

Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 16:00:29 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:26 2004
Subject: What is a document?
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E908F@sohos002.ied-support.net>

Didier PH Martin wrote:
> Conclusion:
> -----------
> According to the actual state of the art, only Hypothesis 1 
> will fly. If we
> think of rendition, we have to think of document. If we think about
> document, then a biztalk message is also a document. The content (your
> message) is only a fragment. In the XML world there is no 
> actual standard
> notions of
> a) envelope
> b) multiple document embedding for transport (each embedded 
> fragment being a
> separate entity interpreted by different agents)

I think this is always the case; according to XML 1.0, a document cannot
be contained within another document. (Of course with SML you can have
as many documents/sentences/fragments as you like in one stream, which
I'm sure will confuse those new to XML, but still, there you have it.)

However, I think that conceptually I prefer your thinking in some of
your previous messages. Shouldn't the means by which a 'document'
arrived at your server be almost irrelevant? The fact that it was
wrapped in BizTalk or SOAP, or was retrieved through WebDAV or DASL or
was emailed with MIME, or picked up by a resource statement in RDF makes
no difference to the content. I would suggest that the stylesheet
instruction to which you refer should be for the enclosed 'document',
which will change - chrysalis-like - from a fragment into a mature
document, able to hold its own in the world and strike out
independently.

(Its difficult to read DIdier without wanting to try a few metaphors -
just to see how it feels.) :-)

It's even conceivable as these systems mature, that if one
route/protocol for delivery was unavailable another would be used, so
you definitely don't want to get too involved in the transport. Anyway,
I think these issues are for the application level, not the XML parser
level.

Regards,

Mark

PS My spell checker wants to change BizTalk to bestial. It's not been
wrong before, so watch out.

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



From Clark.Cooper at bender.com  Mon Nov 22 15:56:53 1999
From: Clark.Cooper at bender.com (Cooper, Clark)
Date: Mon Jun  7 17:17:26 2004
Subject: Parser compliance
Message-ID: <D9F2F531A55CD311AB5D0008C7B1A1955DF431@MBCALBEXC02>

On 17 Nov 1999, Richard Lanyon wrote:
>> Well, Expat is drop-dead, shoot-your-dog-if-it-ain't conformant...
>
> Indeed, but it's not necessarily "fully-featured" in that it doesn't
> include external entities and isn't validating, ...

Expat has been able to handle external entities ever since I started using
it
over a year ago. And more recently (at least in the test version), it has
the
ability to read an external DTD and expand parameter entities.

With this ability, validation can be supported in a higher layer, which, in
my
opinion, is the place for it.

Clark Cooper    Logic Technologies, Inc.     cccooper@ltionline.com
(800)424-4200   650 Franklin St., Suite 304  coopercc@netheaven.com
     ext 3984   Schenectady, NY 12305  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 16:04:26 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:26 2004
Subject: facts, conclusions, and exhortations re XML (long)
In-Reply-To: <Pine.LNX.3.96.991120205655.29374A-100000@www.falconwing.com>
	(message from Sean Chen on Sat, 20 Nov 1999 21:02:53 -0500 (EST))
References: <Pine.LNX.3.96.991120205655.29374A-100000@www.falconwing.com>
Message-ID: <199911211738.LAA01158@bruno.techno.com>

[Sean Chen:]
> I believe the the implementation talked about here is XQL, a
> precursor to XPath.  Nowhere has Microsoft claimed to implement
> XPath yet, AFAIK.  In fact, according to Microsoft, they are
> refusing to implement XSLT or XPath until the final recommendation,
> which has only just happened this week.

> If this problem occurs, after these implementations come out, then
> we can complain =)

Your counsel is wise.  Especially after the court's very recent
finding that Microsoft is a monopoly that has abused its monopoly
power to the detriment of the public interest, we should watch and see
whether Microsoft will act to commoditize or de-commoditize the
interchange of knowledge.  (I know which way I'd bet, but I'd be
delighted to be wrong.)

> We must be careful with our facts.  The problem with XML is that the
> dust is just settling (or not, with XSchemas yet to be done) and
> there are a lot of experimental work out there that is still hanging
> around.

While the dust is still settling is when it's especially easy for
Microsoft to lock in the lion's share of the customers with products
whose functionality meets or exceeds the requirements that the
relevant standards (when they appear) are intended to fulfill.  So the
customer gets everything except the benefits of interchange with
non-Microsoft-based applications.  

Experimentation is fine and necessary, but it's not reasonable to
consider the commercial distribution of many millions of copies of
IE5, including all of the "experimental" and otherwise-proprietary
features of IE5, as an experiment in the same category with other
ongoing XML experimentation.  Consider how much valuable information
is now being encoded in a fashion that is only interpretable by IE5.
What is the aggregate net present value of that information?  Maybe
$0, and maybe a very large amount.  Considering the desperate rush of
increasingly complex businesses to get on the Web, and the lack of
credible competition in the browser market, I'd bet on a very large
amount.

As an XML developer and information management consultant, I urge
customers to calculate the value of their information, and, if the
information has significant value, to protect that value by simply
refusing to use nonstandard proprietary notational practices, thus
keeping their information serviceable by commoditized methodologies
and systems.  Making customers aware of these issues, and providing
them with fully-commoditized options, is what I call "using truth as a
weapon."

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 16:04:48 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:26 2004
Subject: Parser compliance
In-Reply-To: <3.0.5.32.19991119112744.00aec6b0@corp.infoseek.com> (message
	from Walter Underwood on Fri, 19 Nov 1999 11:27:44 -0800)
References: <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>
 <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain> <3.0.5.32.19991119112744.00aec6b0@corp.infoseek.com>
Message-ID: <199911211955.NAA07503@bruno.techno.com>

[Steve Newcomb:]
> >In my own mind, the purpose of XML, as a tool, is to get information (not
> >just data) from A to B.  I think of information as having two forms:
> >
> >(1) ready-to-run objects in memory, e.g. ready-to-roll DOM
> >
> >(2) interchangeable (but otherwise useless) serialized-into-characters
> >    XML

[Walter Underwood:]
> This doesn't begin to cover a lot of what XML is used for. It does
> cover document-like uses, but not the data-serialization uses.
> In the latter, folks want their application objects, not objects
> that accurately reflect the source document. They need something
> more like marshalling/unmarshalling code, going straight to the
> app-meaningful objects.

> Even for some documentation-like uses, a DOM is the wrong answer.
> Our search engine needs to extract text and store it in the indexes.
> Analyzing the documents in a stream (SAX) means handling bigger
> documents, using less memory, et cetera.

My main point is, I think, also yours: it causes unnecessary grief to
assume that the interchange structure of an XML resource needs to be
the same as, or even correspond to, the API to the information that
the XML resource carries.

I mentioned the DOM only as an *example* of ready-to-run objects; I
did not intend to say that the DOM is useful for every purpose.
Ready-to-run objects (including your indexes) are ready-to-run
objects, regardless of the process by which they were created.
Ready-to-run objects (whatever one may call them, and regardless of
how they are implemented) are manufactured by all applications of XML,
not just by some of them.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dhunter at Mobility.com  Mon Nov 22 16:06:44 1999
From: dhunter at Mobility.com (Hunter, David)
Date: Mon Jun  7 17:17:26 2004
Subject: Feeling good about SML
Message-ID: <805C62F55FFAD1118D0800805FBB428D02BC00E2@cc20exch2.mobility.com>

From: Hunter, David [mailto:dhunter@Mobility.com]
>  It's true, I'm a consultant, not a
> Joe-Clueless-User.

Based on the message I just read from David Megginson, I wanted to emphasize
something:  When I say "consultant", I am by no means an "XML consultant".
I consider myself more of a "web development consultant".  I just happened
to find XML easy to use in my projects whenever "information" had to be
shuttled back and forth.

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



From martind at netfolder.com  Mon Nov 22 16:39:35 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:27 2004
Subject: What is a document?
In-Reply-To: <8DCB90532FF7D211B34400805FD48853A94A71@SENMAIL3>
Message-ID: <NBBBJPGDLPIHJGEHAKBAGEEEEHAA.martind@netfolder.com>

Hi Steven,

Steven said:
I would say the content is the document. The BizTalk framework will simply
allow content to be transported in a message format, telling processers
which understand the relevent tags (ie. the BizTalk environment) what to do
with the content - where to route it etc...

I suppose it's much like posting a letter, where your content is hidden
within the envelope and the envelope simply has instructions (ie. Airmail,
Address etc..) on how the envelope should be handled? - Not sure about
postcards though?

That's a bit simple to explain the entire framework, but some BizTalk
processing would have to be done, although there is no reason why you should
not be able to directly extract the XML content within the <message> tags?

Didier reply:
I am not so sure. It depends mainly how the document is delivered to the
receiving end.

Hypothesis 1:
------------
The biztalk message is delivered as is to the receiving end. In this case,
the document is the biztalk message and not the message content.

Hypothesis 2:
-------------
The biztalk engine removes the biztalk "envelope" and just send the content.
In this case, the content is the document, not the biztalk message (i.e. the
envelope + the content).

So it depends mainly on what is sent to the recipient. If the biztalk system
is used as an internal message passing system then, the content is seen
externally as the document (the biztalk envelope is removed). For instance,
you trading partner is supporting the eco framework (ref:
http://eco.commerce.net) and cxml. In that case, the trading partner do not
understand a biztalk message, the biztalk server has to send only the
content.

On the other hand, if the receiving end, understand biztalk then the content
is not the document, only a fragment. A fragment handler will be matched
with the message content and the content processed. But the whole biztalk
message is then the received document. Let's say now that all the received
biztalk messages are stored in a folder. You want to display one of them.
The sender also provided a style sheet so that you can render the document.
<Question> where is located the <xml-stylesheet> PI? in the content fragment
or at the beginning of the biztalk message?. What is the scope of the
stylesheet? the biztalk message or the message content?
If the sender biztalk engine included the content's style sheet in its own
style sheet, then the receiving end will have to:
a) extract the content
b) extract from the biztalk message the content's style sheet
c) produce a document with the content and the content's style sheet.

Off course this would have been simpler if the fragment got its own style
sheet but a stylesheet has the whole document as a scope not a fragment.

What could then be the behavior of a browser if two different style sheets
are present in the same document? each one targeted to the "screen" media.
Does the browser takes the first style sheet for a certain scope and the
other for the fragment? I doubt, the implicit scope of action for a style
sheet is the document, not a fragment. So, how can I render both the
envelope and the content with the following constraints:
a) the envelope is rendered the way the envelope creator wanted
b) the message's content is rendered the way the content's creator wanted.

Solution 1:
-----------
Both the envelope and the content have a separate style sheet. Question: is
this document a valid XML+XSLT  document (if XSLT is used for styling)?

solution 2:
-----------
The biztalk message include a single style sheet which includes (i.e import)
the content style sheet. The biztalk message has only one stylesheet. Then,
in that case, the biztalk message becomes the document, not the content.

solution 3:
-----------
Or both the biztalk envelope and the content have each separate style
sheets. In this case, there is an implicit rule that the content is always
removed for processing and that a biztalk message is not a document. That it
cannot be processed for rendition before the content is removed from the
envelope. Or that is has first to be splitted into two documents 1) the
envelope, 2) the content. This implies that a biztalk message is not a
displayable message per se and that some extraction has to be performed
before rendition.

You see funny problems brought by using XML as data exchange tools and that
this format is also a document format. Therefore a data exchange gizmo is
also a document and as such could be rendered with document rendition tools.
However, we do not have such standards concepts in the XML world for things
like
1) envelope (like found in telecom)
2) multiple rendition scope ( a style sheet attached to a particular
fragment)

My own conclusion with the actual XML state of the art: the biztalk message
is the document not the message content.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Mon Nov 22 16:46:55 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:27 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E908F@sohos002.ied-support.net>
Message-ID: <NBBBJPGDLPIHJGEHAKBAAEEHEHAA.martind@netfolder.com>

Hi Mark,

Mark said:
PS My spell checker wants to change BizTalk to bestial. It's not been
wrong before, so watch out.

Didier reply:
Mark I am still laughing :-))) That's a good one that I'll remember.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Mon Nov 22 17:06:43 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:27 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E908F@sohos002.ied-support.net>
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEEHEHAA.martind@netfolder.com>

Hi Mark,

Mark said:
However, I think that conceptually I prefer your thinking in some of
your previous messages. Shouldn't the means by which a 'document'
arrived at your server be almost irrelevant? The fact that it was
wrapped in BizTalk or SOAP, or was retrieved through WebDAV or DASL or
was emailed with MIME, or picked up by a resource statement in RDF makes
no difference to the content. I would suggest that the stylesheet
instruction to which you refer should be for the enclosed 'document',
which will change - chrysalis-like - from a fragment into a mature
document, able to hold its own in the world and strike out
independently.

Didier reply:
Yes mark, if we got the notion of scope for rendition it would be a lot
easier to assemble fragment/documents into a whole. Obviously, each
assembled part would have to take into account that it is included in a
whole for rendition (i.e like an HTML+CSS document for example). But, this
could be the beginning of modularity and re-use. So, what required though is
the concept of "scope of rendition".

Theoritically, if the rendition language to be used is XHTML+CSS, then it
should be possible to mix other domain languages (based on XML) with a CSS
style sheet and XML to XHTML transformed elements. Thus, the result could
be:


fragment 1 ----> CSS style sheet
   |____ fragment 1.1 --------> CSS style sheet
   |		|___ Fragment 2.1 ---------> XSLT style sheet
   |____ Fragment 1.2 --------> XSLT style sheet

So, what is missing is the notion of "aggregation" and the notion of "scope
of rendition". This could promote re-use and modularity.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 17:21:04 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:17:27 2004
Subject: What is a document?
Message-ID: <8DCB90532FF7D211B34400805FD48853A94A8C@SENMAIL3>

Hi Didier - 
I suppose to an extent it also depends on what part of the process you look
at.

For the company creating the an instance of a schema, they have their XML
document - ie. a 3rd party requesting a stock order.
This may then be wrapped in the BizTalk framework by a "transparent"
application (say) and create a new BizTalk doc.

When it reaches the other side, it is a BizTalk doc, but the output of the
receiving app is the original XML doc.

So which one's the XML doc? i Suppose it depends who/what is using it?

I guess there would have to be two stylesheets - one for the BizTalk
framework and another for the schema in question.

I would guess SOAP is slightly different though, as it's goal isn't really
to wrap XML docs, but rather uses (usually) XML to wrap remote method calls
for objects.

As Mark says though, it probably won't matter to most people, as the BizTalk
and SOAP tags will be transparent.

cheers,
steven

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Didier PH Martin [SMTP:martind@netfolder.com]
> Sent:	22 November 1999 16:38
> To:	Steven Livingstone, ITS, SENM; 'XML Dev'
> Subject:	RE: What is a document?
> 
> Didier reply:
> I am not so sure. It depends mainly how the document is delivered to the
> receiving end.
> 
> Hypothesis 1:
> ------------
> The biztalk message is delivered as is to the receiving end. In this case,
> the document is the biztalk message and not the message content.
> 
> Hypothesis 2:
> -------------
> The biztalk engine removes the biztalk "envelope" and just send the
> content.
> In this case, the content is the document, not the biztalk message (i.e.
> the
> envelope + the content).
> 
> So it depends mainly on what is sent to the recipient. If the biztalk
> system
> is used as an internal message passing system then, the content is seen
> externally as the document (the biztalk envelope is removed). For
> instance,
> you trading partner is supporting the eco framework (ref:
> http://eco.commerce.net) and cxml. In that case, the trading partner do
> not
> understand a biztalk message, the biztalk server has to send only the
> content.
> 
> On the other hand, if the receiving end, understand biztalk then the
> content
> is not the document, only a fragment. A fragment handler will be matched
> with the message content and the content processed. But the whole biztalk
> message is then the received document. Let's say now that all the received
> biztalk messages are stored in a folder. You want to display one of them.
> The sender also provided a style sheet so that you can render the
> document.
> <Question> where is located the <xml-stylesheet> PI? in the content
> fragment
> or at the beginning of the biztalk message?. What is the scope of the
> stylesheet? the biztalk message or the message content?
> If the sender biztalk engine included the content's style sheet in its own
> style sheet, then the receiving end will have to:
> a) extract the content
> b) extract from the biztalk message the content's style sheet
> c) produce a document with the content and the content's style sheet.
> 
> Off course this would have been simpler if the fragment got its own style
> sheet but a stylesheet has the whole document as a scope not a fragment.
> 
> What could then be the behavior of a browser if two different style sheets
> are present in the same document? each one targeted to the "screen" media.
> Does the browser takes the first style sheet for a certain scope and the
> other for the fragment? I doubt, the implicit scope of action for a style
> sheet is the document, not a fragment. So, how can I render both the
> envelope and the content with the following constraints:
> a) the envelope is rendered the way the envelope creator wanted
> b) the message's content is rendered the way the content's creator wanted.
> 
> Solution 1:
> -----------
> Both the envelope and the content have a separate style sheet. Question:
> is
> this document a valid XML+XSLT  document (if XSLT is used for styling)?
> 
> solution 2:
> -----------
> The biztalk message include a single style sheet which includes (i.e
> import)
> the content style sheet. The biztalk message has only one stylesheet.
> Then,
> in that case, the biztalk message becomes the document, not the content.
> 
> solution 3:
> -----------
> Or both the biztalk envelope and the content have each separate style
> sheets. In this case, there is an implicit rule that the content is always
> removed for processing and that a biztalk message is not a document. That
> it
> cannot be processed for rendition before the content is removed from the
> envelope. Or that is has first to be splitted into two documents 1) the
> envelope, 2) the content. This implies that a biztalk message is not a
> displayable message per se and that some extraction has to be performed
> before rendition.
> 
> You see funny problems brought by using XML as data exchange tools and
> that
> this format is also a document format. Therefore a data exchange gizmo is
> also a document and as such could be rendered with document rendition
> tools.
> However, we do not have such standards concepts in the XML world for
> things
> like
> 1) envelope (like found in telecom)
> 2) multiple rendition scope ( a style sheet attached to a particular
> fragment)
> 
> My own conclusion with the actual XML state of the art: the biztalk
> message
> is the document not the message content.
> 
> Cheers
> Didier PH Martin
> mailto:martind@netfolder.com
> http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 18:37:44 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:27 2004
Subject: SGML, XML and SML
Message-ID: <007a01bf351c$20746a80$59f96d8c@NT.JELLIFFE.COM.AU>

 From: Don Park <donpark@docuverse.com> 

>>Well, it is not XML at all if  it miss-parses a well-formed XML
>>document.
>>
>><a>
>>    <?b </a> ?>
>>    <!-- </a> -->
>>    <![CDATA[ </a> ]]]>
>></a>
>
>Rick, I think you are actually picking an example favoring
>the use of SML.  It might be legal XML but it is also a
>bracketed ball of mess.  Besides, SML processors can't
>parse full XML just as XML parsers can parse full SGML.
 
No, every XML document is a legitimate WebSGML document.
But would every SML document be a well-formed XML document?

That example is one that SML would have to have a policy on:
one that would constrain documents to being XML is to barf
whenever <!  or <? was found.
    
If you want a less bracketed mess, then pick any one of
    <a><!-- <a/>  --></a>
or
    <a><!?x <a/>  ?></a>
or 
   <a><![CDATA[ <a/>  ]]></a>

Or even:
<p>In HTML, use the &lt;!-- comment delimiter open </p>


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 18:47:22 1999
From: roddey at us.ibm.com (roddey@us.ibm.com)
Date: Mon Jun  7 17:17:27 2004
Subject: Grafting DOM on a C++ XML parser?
Message-ID: <87256831.006730B9.00@d53mta03h.boulder.ibm.com>




> Note: David Brownwell's conformance articles did NOT cover
> our IE5 COM based MSXML.DLL.

Nor does it use our latest XML4C/J versions, so it is out of date in that
regard as well.

----------------------------------------
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 19:52:01 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:27 2004
Subject: SGML, XML and SML
In-Reply-To: <3.0.32.19991122072523.0145b100@pop.intergate.ca>
Message-ID: <000e01bf3523$5b5e56e0$099918d1@docuverse1>

Tim Bray wrote:
>And SML must not claim, explicitly or implicitly, to "be XML".

I think this condition can be met.  We will make it clear that:

SML is a subset of XML and is not to be considered, in any sense,
as conforming to the full XML 1.0 specification.

If you have better wordings, I'll be obliged.  It is not my
intention to sabotage XML in-flight.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 19:51:55 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:27 2004
Subject: SGML, XML and SML
In-Reply-To: <007a01bf351c$20746a80$59f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000d01bf3523$5a51c8e0$099918d1@docuverse1>

>No, every XML document is a legitimate WebSGML document.
>But would every SML document be a well-formed XML document?

No.  SML has no concept of documents.  Every SML data is a
external parsed XML entity.

>If you want a less bracketed mess, then pick any one of
>    <a><!-- <a/>  --></a>
>or
>    <a><!?x <a/>  ?></a>
>or 
>   <a><![CDATA[ <a/>  ]]></a>
>
>Or even:
><p>In HTML, use the &lt;!-- comment delimiter open </p>

First three is failed by SML processor.  Last should pass.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 20:34:25 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:27 2004
Subject: What is a document?
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAKEEHEHAA.martind@netfolder.com>
Message-ID: <001701bf3529$46757fa0$099918d1@docuverse1>

>So, what is missing is the notion of "aggregation" and the 
>notion of "scope of rendition". This could promote re-use
>and modularity.

Bingo.  My, previously unstated, thinking is that certain
design choices made at syntax level can encourage this line
of thinking.  If people can only create modules, they will
have to create modules. <g>

As far as the question "What is a document?" is concerned,
my view is that a document is an end-product and thus has a
sense of wholeness which runs counter to the ideals of
reusability and modularity.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 21:05:32 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun  7 17:17:27 2004
Subject: Grafting DOM on a C++ XML parser?
References: <87256831.006730B9.00@d53mta03h.boulder.ibm.com>
Message-ID: <3839B012.1ACE6A36@pacbell.net>

roddey@us.ibm.com wrote:
> 
> > Note: David Brownwell's conformance articles did NOT cover
> > our IE5 COM based MSXML.DLL.

Fixed, as noted in a few followups.  See www.XML.com right now!


> Nor does it use our latest XML4C/J versions, so it is out of date in that
> regard as well.

Re the C parser, that was explicitly a non-goal:  it tested things
using standardized _Java_ bindings (SAX).  As stated repeatedly in
that article.  

Re the Java version, the version in that article is still the latest
commercially licensed version (2.0.15).  The review is not "out of
date" even though IBM subsequently released a noncommercial "EA2".

With the care IBM invested in ensuring that the "EA2" version not
be licensed for products, it'd be inappropriate to review EA2 unless
the 2.0.15 release gets withdrawn in its favor.

- 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 21:24:27 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:27 2004
Subject: SGML, XML and SML
References: <000e01bf3523$5b5e56e0$099918d1@docuverse1>
Message-ID: <008401bf352f$bed79e00$5df5c13f@PaulTchistopolskii>



I think that SML vs XML is *very* similiar to
XML vs SGML.

XML exists because SGML has beed
considered to be 'too hard'  for learning and
'too heavy'  for placing into thin client. Right ?

SML could appear because actualy now
XML  *could* be considered to be 'too hard'
and 'too heavy'. Even not talking about the
namespaces.

SML proposal is nice.

Is there a URL keeping  the 'latest SML specification
draft'  ?

The funny thing is that after simplifying the XML
itself, next steps could ( would ) be:

1. Simplify SAX  1.0 ...

...  not talking about some complex processing ....
if just copying *unchanged* XML file  incuding
comments, and references to external ( missing)
DTDs from input to output  with SAX 1.0 ...

Creating fake EntityResolver... Using proprietary
APIs to keep comments and CDATA ( and
not every XML parser has such an API!) ... well ..
Was it  <A></A> or just <A/> ?

Such a mess...  Unfortunately, to me
SAX2 is not an answer, because it makes
things more complex ( yes,  it's because XML
gets more complex, but if starting with SML ... ;-)

2. Simplify XSLT. Just to make it easy to embed
XML + XSL processing into some client with small
memory.  ;-)

Actualy, the question about the memory is not that
simple. It sometimes comes to 'java or not java'.
'Java or not java' is a result of many things including
personal preferences of some well-known
developers. I mean " it is java because it is hard to
re-invent it and the preson who invented it - he likes
java ".

SML-based *tools*  have bigger probability to
get implemented by wider range of developers.

3. Simplify DOM ,  XQL ( or XML-QL ) e t.c. e t.c.

I'm not saying that SML *requires*  those
changes ;-) I'm saying that SML appearance
could have *such* an impact on XML ( like XML
appearance killed SGML, even at the beginning
I think nobody was thinking to kill SGML with
XML ? Or the idea was to kill SGML ?

The more I think about SML ....

... validation and entities could go away  from
the core ...  They are optional and could be done
with (optional) levels of processing.

Why should one place macroprocessor ( SYSTEM
and entities in fact *are* just macroprocessor
instructions ) into the *core* ?

What's wrong with m4 ? ;-)

OK ...  OK ... Let's face it. XML could be considered
to be bloated ( maybe a bit - but it counts, if we'l
take into account that XML is the *core* and
everything else ( XSLT, XSLQL, DOM e t.c.) is
based on the core ).

XML is much simpler  than SGML, but it still is
not as simple as it could (?) be.

I think there are some developers  who want
*very*  weak DTD-based validation and weak
macroprocessor  to reside in the core. But I'm also
sure that there are some other developers who
want strong ( Yacc-based ) validation on server side,
strong macroprocessing on server side and
*then*  efficient SML-based client *not*  bloated
with some useless  features. ;-)

Rgds.Paul.

> Tim Bray wrote:
> >And SML must not claim, explicitly or implicitly, to "be XML".
>
> I think this condition can be met.  We will make it clear that:
>
> SML is a subset of XML and is not to be considered, in any sense,
> as conforming to the full XML 1.0 specification.
>
> If you have better wordings, I'll be obliged.  It is not my
> intention to sabotage XML in-flight.
>
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 21:39:26 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:28 2004
Subject: What is a document?
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E9092@sohos002.ied-support.net>

Didier PH Martin wrote:
> Didier reply:
> Yes mark, if we got the notion of scope for rendition it 
> would be a lot
> easier to assemble fragment/documents into a whole. Obviously, each
> assembled part would have to take into account that it is 
> included in a
> whole for rendition (i.e like an HTML+CSS document for 
> example).

I wouldn't impose such a limitation myself. Why should the fragment
'know' anything about its container? (If I understand you correctly -
and apologies if I don't.) Provided it has its namespace declaration
then it can in theory exist in any container that will have it.

In fact, with RDF you could just wrap some XML in a CDATA tag and bung
it in a description. Or you can place it in a BizTalk 'envelope', or you
can use MIME, or even package it up with headers and send it through
HTTP/WebDAV. Each of these has different notions of validity. RDF or
BizTalk (or XML Fragment Interchange) require that the containing
document is well-formed XML with its contained object(s). But a
PROPPATCH in WebDAV requires that the containing document is well-formed
HTTP (plus a bit), and the document describing the elements being
patched are well-formed XML. So we have different notions of
'correctness' with different transports.

So, we have the notion of a document that we need to transport, and it
has its own requirements as to well-formedness, validity, etc. And then
we have the transport mechanism which has its own means of communicating
errors, etc.. And in some situations XML will be used as the transport
mechanism - as with BizTalk - but I don't think it should logically be
treated any different to other transport mechanisms. (Of course it's
handy to have it as XML because we can use all our other tools to handle
transport.)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kragen at pobox.com  Mon Nov 22 21:53:46 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:17:28 2004
Subject: SGML, XML and SML
Message-ID: <Pine.GSO.4.10.9911221641440.23518-100000@kirk.dnaco.net>

Don Park writes:
> SML is a subset of XML and is not to be considered, in any sense,
> as conforming to the full XML 1.0 specification.
> 
> If you have better wordings, I'll be obliged.  It is not my
> intention to sabotage XML in-flight.

Usually, when people talk about languages in set-theoretic terms, they
are referring to the sets of strings that belong to the languages.  If
language A is a subset of language B, that means every string that is a
valid sentence (or document, or program, or whatever) in language A is
also valid in language B.  Usually they also mean that strings valid in
both languages have the same meanings in both.

Obviously there are SML "documents" that are not valid XML documents,
such as "<x/><y/>", so the first sense doesn't apply.  I'm not clear
about whether the second applies or not.

You might mean that the specification of SML consists of pieces of the
specification of XML, but that's not true either.

Perhaps you could say SML is a simplified version of XML.

Also, a nitpick: language specifications don't conform to the XML spec,
unless they are written in XML; XML documents do.  Perhaps you should
say that SML documents do not necessarily conform to the XML
specification.

A note: I am enthusiastic about the idea of a stream-based XML
variant.  I've always thought of it as a flaw that XML documents cannot
concatenate to form other XML documents -- i.e. XML is not closed under
concatenation -- and, due to the fact that <?xml version="1.0"?> is not
a PI, you can't include an arbitrary XML document inside another XML
document -- another flaw, in my view.

I think it would be very nice, from a processing point of view, to have
an XML variant that didn't have CDATA sections or DTDs (although entity
definitions are useful!).  I suspect CDATA sections are hard to live
without if you're writing XML documents about HTML or XML, though.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 22:05:21 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:28 2004
Subject: SGML, XML and SML
In-Reply-To: <008401bf352f$bed79e00$5df5c13f@PaulTchistopolskii>
Message-ID: <000201bf3535$fcd32ca0$099918d1@docuverse1>

>SML proposal is nice.

Thanks.

>Is there a URL keeping  the 'latest SML specification
>draft'  ?

I am still working on it.  When I am ready to show it, I think the
likely temporary URL will be http://www.docuverse.com/sml/smlspec.html

As I am not allowed to use the XML 1.0 spec to create the SML spec
without review by W3C, I have started writing from scratch so it might
take a bit of time.  Once the first draft is up, we can start arguing about
the specifics.

Since I have already made a statement to the effect that I'll eat the SML
spec if it doesn't fly, I am most keen to keep the spec short enough to
digest easily (literally :-).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 22:18:40 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:28 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E9092@sohos002.ied-support.net>
Message-ID: <000401bf3537$d8b558a0$099918d1@docuverse1>

>I wouldn't impose such a limitation myself. Why should the fragment
>'know' anything about its container? (If I understand you correctly -
>and apologies if I don't.) Provided it has its namespace declaration
>then it can in theory exist in any container that will have it.

We clearly have a need to delve deeper into XML fragments related
issues and I believe this is one of them.

In my view, sometimes it makes sense for a particular XML fragment
to specify constraints on its containers.  By its nature, a fragment
is likely to be missing some information (parameters if you will) that
must be provided by the context.  We currently have no mechanism to do
this but we will need it eventually.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Mon Nov 22 22:53:28 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:28 2004
Subject: What is a document?
References: <000401bf3537$d8b558a0$099918d1@docuverse1>
Message-ID: <00b401bf353c$96bc5ca0$0b00a8c0@grissom>

<< for a particular XML fragment to specify constraints on its containers.
By its nature, a fragment
is likely to be missing some information (parameters if you will) that must
be provided by the context.

Constraints at more than one level is consistent with the SQL model, which
includes constraints on tables or columns.







xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 22 22:59:02 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:28 2004
Subject: SGML, XML and SML
In-Reply-To: "Don Park"'s message of "Mon, 22 Nov 1999 14:07:29 -0800"
References: <000201bf3535$fcd32ca0$099918d1@docuverse1>
Message-ID: <m37ljannfz.fsf@localhost.localdomain>

"Don Park" <donpark@docuverse.com> writes:

> As I am not allowed to use the XML 1.0 spec to create the SML spec
> without review by W3C, I have started writing from scratch so it
> might take a bit of time.  Once the first draft is up, we can start
> arguing about the specifics.

Obviously you cannot cut and paste, but I see no reason that SML
cannot refer to the XML 1.0 spec just as any other XML-based spec (W3C
or otherwise) can.  That's only fair.

The problem is not whether SML documents will be XML or not (they
probably will), but whether processors that handle SML and not XML
will be XML processors (they definitely won't).

What killed SGML for me and my customers was a lack of adequate
software support in Web languages (Java and Perl) and a brilliant but
extremely complex and mostly undocumented library in C++ (SP).  With
identical software support, I very much doubt that SGML's extra
complexity would have cost my customers any extra time or money at
all, or that SML's extra simplicity would save them any.

> Since I have already made a statement to the effect that I'll eat
> the SML spec if it doesn't fly, I am most keen to keep the spec
> short enough to digest easily (literally :-).

The problem with SGML was that almost no one except James Clark or a
well-funded university research project had the time and energy to
create the SGML libraries in the first place (I know, I tried to do it
in Java).  By comparison, I had AElfred doing useful parsing in the
first couple of hours, and could handle most documents in a couple of
days (adding character set support and tuning the performance took a
little longer) -- it was an order of magnitude simpler to write an XML
parser than it was to write a general SGML parser.

So, for SML to fly, it will not only have to be another order of
magnitude easier to implement than XML (which is entirely possible),
but that order of magnitude will have to cross a significant theshold.

We already have more than adequate free XML parsing support in Java,
C, C++, Perl, Python, Tcl, etc. etc., so SML doesn't buy us anything
(the cost of using an existing free parser is 0, and SML cannot
possibly take less than 0 to implement).  In other words, to keep
paper and printer ink out of his diet, Don will need the following
two things to happen:

1. there will have to be an important new platform or language without
   existing XML support; and

2. the difference in cost and time of implementing XML support on that 
   platform will have to clearly outweight the advantages of
   interoperability.

It is entirely possible that small devices like cell phones could be
just such a platform, but I'm not convinced -- a simple,
non-validating XML parser takes only a few days to write and debug,
the difference between a few person-days and a few person-hours won't
usually justify abandoning the enormous benefit of interoperability.
People have put forward arguments about memory usage, but those were
all trivially easy to answer, so we're still dangling.

Of course, I've been wrong often before, and I'm not an expert in
small or embedded devices, so I'll look forward to seeing what
happens.  I do think that small devices will be at the centre of
computing in the next decade (and a mostly MS-free centre, to boot).
I'm also looking forward to the big 3COM antitrust trial in 2009.


All the best, and good luck,


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 22 23:02:37 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:28 2004
Subject: SGML, XML and SML
References: <Pine.GSO.4.10.9911221641440.23518-100000@kirk.dnaco.net>
Message-ID: <00e101bf353c$18ec1c20$5df5c13f@PaulTchistopolskii>



> I think it would be very nice, from a processing point of view, to have
> an XML variant that didn't have CDATA sections or DTDs (although entity
> definitions are useful!).  

1. Why entities should live in the core, if one can use  
any macroprocessor to get  *more*  flexible functionality?

2. How often do we need entities outside the DTD's ?

> I suspect CDATA sections are hard to live
> without if you're writing XML documents about HTML or XML, though.

Let us have <CDATA> element ? I think up to 3-5 elements with 
'hardcoded' semantics will not cause a big problem.

I think it is not  a big problem in traditional languages 
to use reserved keywords to avoid function names like 
for() or if()  ;-)

However, this suggestion kills compatibility with XML.

It's why I think that SML vs XML is very similiar to 
XML vs SGML.

At some point it would be easier to break the 
compatibility than to support legacy. As far as I 
understand, exactly that thing happened with 
XML vs SGML. 

However, because usualy that CDATA  is all 
about turning < >    into &lt; and &gt;  it may be OK  
to live without CDATA at all - we *already*  have 
similiar problems with XML ;-)

Rgds. Paul.




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



From kragen at pobox.com  Mon Nov 22 23:15:23 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:17:28 2004
Subject: 
Message-ID: <Pine.GSO.4.10.9911221812330.26580-100000@kirk.dnaco.net>

Paul wrote:
> Kragen wrote:
> > I think it would be very nice, from a processing point of view, to have
> > an XML variant that didn't have CDATA sections or DTDs (although entity
> > definitions are useful!).  
> 
> 1. Why entities should live in the core, if one can use  
> any macroprocessor to get  *more*  flexible functionality?
>
> 2. How often do we need entities outside the DTD's ?

Well, I think it's important to be able to include (a) < and & and (b)
characters outside my charset.

> > I suspect CDATA sections are hard to live
> > without if you're writing XML documents about HTML or XML, though.
> 
> Let us have <CDATA> element ? I think up to 3-5 elements with 
> 'hardcoded' semantics will not cause a big problem.
> 
> I think it is not  a big problem in traditional languages 
> to use reserved keywords to avoid function names like 
> for() or if()  ;-)

Interesting idea.  But it would be just as hard to process as the
current ]]> kludge; what is the benefit?

> However, this suggestion kills compatibility with XML.

But not SGML :) :)

> It's why I think that SML vs XML is very similiar to 
> XML vs SGML.
> 
> At some point it would be easier to break the 
> compatibility than to support legacy. As far as I 
> understand, exactly that thing happened with 
> XML vs SGML. 

. . .but XML is a subset of SGML.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov 22 23:46:17 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:28 2004
Subject: SGML, XML and SML
References: <Pine.GSO.4.10.9911221641440.23518-100000@kirk.dnaco.net>
Message-ID: <001701bf3542$ba4486b0$35d88dce@WORKGROUP>


----- Original Message -----
From: Kragen Sitaker <kragen@pobox.com>
To: <xml-dev@ic.ac.uk>
Sent: Monday, November 22, 1999 4:54 PM
Subject: Re: SGML, XML and SML



>
> I think it would be very nice, from a processing point of view, to have
> an XML variant that didn't have CDATA sections or DTDs (although entity
> definitions are useful!).  I suspect CDATA sections are hard to live
> without if you're writing XML documents about HTML or XML, though.
>

I've agonized about this a bit.  Clearly SML needs some escape mechanism so
that this can be done. I presume it will be dear old &lt; and &gt;  But so
long as *tools* make it easy to insert a block of XML or HTML and will do
the grunt work of the escaping, I'm not at all convinced that this needs to
be supported with CDATA sections in the language itself.

Also, for that matter, one might argue that SML does not need CDATA sections
because it has no notion of validity, or even a distinction between CDATA
and PCDATA elements.  So long as the XML or HTML document being "quoted" is
well formed, it can go inside any SML tag pair.  (Or am I missing something
here?)




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



From KenNorth at email.msn.com  Tue Nov 23 00:02:33 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:28 2004
Subject: XML One expert panel now playing on TechNetCast
Message-ID: <00d201bf3546$57bdc2a0$0b00a8c0@grissom>

The November 11 XML One expert panel discussion was recorded and is
available on the Web.

Panelists were from W3C XML working groups, OASIS, XML/EDI Group, Bluestone
Software, Commerce One, eProcess Solutions, IBM, Informix, Microsoft,
Oracle, and Sun. To hear them discuss XML standards, e-commerce, BizTalk,
ebXML, and XML-enabled databases, tune to the URL below:

http://technetcast.ddj.com

If you don't have Real Player, you can download it free from this site.
Panel members were:

David Booth, Senior Research Architect, Bluestone Software
David Fallside, XML Technology and Strategy team, IBM
Matthew Fuchs, Common Business Library Architect, Commerce One
Sam Hamilton, XML Architect, Informix
Steve Muench, BC4J architect, XML Evangelist, Oracle
Bruce Peat, Co-founder, XML/EDI Group, eProcess Solutions
Dan Rogers, BizTalk Program Manager, Microsoft
Bill Smith, OASIS President, XML architect, Sun

Fallside, Fuchs, Muench, and Smith are participants in W3C XML/XSL Working
Groups.

Moderated by Ken North, Contributing Editor of Web Techniques, author of
Database Magic with Ken North.





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



From clark.evans at manhattanproject.com  Tue Nov 23 00:34:08 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:28 2004
Subject: What is a document?
In-Reply-To: <NBBBJPGDLPIHJGEHAKBACEDPEHAA.martind@netfolder.com>
Message-ID: <Pine.LNX.4.10.9911220725280.7492-100000@cauchy.clarkevans.com>

On Mon, 22 Nov 1999, Didier PH Martin wrote:
> Continuing the reflection on biztalk like XML formats, a question occurred
> in my mind: In a biztalk like message, what is the document?

I'm not sure that the BizTalk approach is all that wise.

It seems that choosing MIME would have been far better.
Thus, the message contains two documents; a BizTalk
routing document and the 'content' document.  This allows 
for other routing protocols to be used with the 
message -- simply add another document to the binder.

This reminds me of Red Hat's RPM format.  They could
have simply used pkzip or gzip and included a MANIFEST 
section... just like Java's JAR files, which IMHO, 
is the right way to do it.

;) Clark


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



From clark.evans at manhattanproject.com  Tue Nov 23 00:35:56 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:28 2004
Subject: SGML, XML and SML
In-Reply-To: <Pine.GSO.4.10.9911221641440.23518-100000@kirk.dnaco.net>
Message-ID: <Pine.LNX.4.10.9911220734430.7492-100000@cauchy.clarkevans.com>


On Mon, 22 Nov 1999, Kragen Sitaker wrote:
> A note: I am enthusiastic about the idea of a stream-based XML
> variant.  I've always thought of it as a flaw that XML documents cannot
> concatenate to form other XML documents -- i.e. XML is not closed under
> concatenation -- and, due to the fact that <?xml version="1.0"?> is not
> a PI, you can't include an arbitrary XML document inside another XML
> document -- another flaw, in my view.

I'd *love* to hear more about this.

;) Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 01:25:25 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:29 2004
Subject: SML
References: <Pine.GSO.4.10.9911221812330.26580-100000@kirk.dnaco.net>
Message-ID: <013901bf354f$da47f2a0$5df5c13f@PaulTchistopolskii>



> Paul wrote:
> > Kragen wrote:
> > > I think it would be very nice, from a processing point of view, to have
> > > an XML variant that didn't have CDATA sections or DTDs (although entity
> > > definitions are useful!).  
> > 
> > 1. Why entities should live in the core, if one can use  
> > any macroprocessor to get  *more*  flexible functionality?
> >
> > 2. How often do we need entities outside the DTD's ?
> 
> Well, I think it's important to be able to include (a) < and & and (b)
> characters outside my charset.

Agree ... there is  some need in #defines in .c files, but 
mostly they are located in .h files ;-)

I still think that macroprocessor could live outside the core
( even macroprocessor  is a handy thing ) - I think it may  
result in better design, better documents  e t.c.
 
> > > I suspect CDATA sections are hard to live
> > > without if you're writing XML documents about HTML or XML, though.
> > 
> > Let us have <CDATA> element ? I think up to 3-5 elements with 
> > 'hardcoded' semantics will not cause a big problem.
> > 
> > I think it is not  a big problem in traditional languages 
> > to use reserved keywords to avoid function names like 
> > for() or if()  ;-)
> 
> Interesting idea.  But it would be just as hard to process as the
> current ]]> kludge; what is the benefit?

It's all very subtile, of course,  but if we could live with 
only :

elements + 
3-5 'predefined' elements  +
comments 

it could be easier to learn and to remember the 
entire thing, I think.

To be honest, I don't  remember the format of 
*all*  the possible kludges I have to learn
during my life. Actualy  I don't understand why  
I have to learn many of  those kludges. 

Because  'clean' solution  makes some 
language purist happy ? What is "clean" ?
It's the issue of taste, I think.
 
I agree that the way it goes is that programmers 
become integrators. If talking about the integration 
it's better to have no kludges than to have 
some. 

SML could become the *extremely* clear 
glue. With 3-lines length specification  and 
trivial filters to/from XML turning 
CDATA element into CDATA kludge, 
for example. ;-)

If  SML has only elements , comments and  
characters   -  one could  easy replace 
<tag_number_1> with <1> on the server, 
then  decompress <1> with <tag_number_1>
on the client with  *extremely* trivial ( short ) 
code. In any language, In one day. Don't think  
it could be done with XML that easy. 
Keeping kludges will make in a  *bit*  more 
messy, but sometimes it counts, so why 
not dropping everything that could be 
dropped ?  ;-)

Also, it is easier to learn and to remember <CDATA> tag 
than CDATA  kludge. Don't  you agree ?

However, I think that CDATA should be killed, if 
compatibility with XML is the unavoidable 
requirment ( and I think it's better  to saticfy 
such a requirment ). 

After CGI and HTML practice,  escaping suspicious 
charachters with ( predefined and hardcoded ) entities 
is now OK. 

> > However, this suggestion kills compatibility with XML.
> 
> But not SGML :) :)
> 
> > It's why I think that SML vs XML is very similiar to 
> > XML vs SGML.
> > 
> > At some point it would be easier to break the 
> > compatibility than to support legacy. As far as I 
> > understand, exactly that thing happened with 
> > XML vs SGML. 
> 
> . . .but XML is a subset of SGML.

Legacy, legacy ... 

Actualy  there is a *huge* work  to create XML-based 
*framework* - I can't belive one developer could create 
it even using existing components.  

The entire 'lite'  SML-based framework  could be written 
by one person from stratch and with some filters to / from XML 
( to / from SGML ) ( or without such )  it could utilize existing 
XML  /  SGML tools 

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 01:39:15 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:29 2004
Subject: Parser compliance
References: <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain>
	 <Pine.LNX.4.10.9911181037030.14885-100000@localhost.localdomain> <3.0.5.32.19991119112744.00aec6b0@corp.infoseek.com> <199911211955.NAA07503@bruno.techno.com>
Message-ID: <3839E4B6.48DD@hiwaay.net>

Steven R. Newcomb wrote:
> 
> My main point is, I think, also yours: it causes unnecessary grief to
> assume that the interchange structure of an XML resource needs to be
> the same as, or even correspond to, the API to the information that
> the XML resource carries.

That is true.  An API is designed to be an interface to information; 
not the other way around.  But define the lexical types, freeze the
features 
sets (probably not a good idea, IMO), declare namespaces and schemas,
and 
you get a good enough structure to manage information for many kinds 
of easily proven good bits of information for reasonable transactions 
among interfaces, the system boundaries.

Define what goodness in information is:  coherence.  

Declare a lexicon, let namespace families aggregate by 
frequency and control referents (W)),  that when valid, 
do not degrade the value of W which may be modeled as phasing. 
Coherence is the capacity of the namespace family to carry 
information with the least noise through the most cycles.

Given a set of XML application languages (vocabularies), what element 
names are being shared and do these conflict semantically?  How is this
detected?

Markup needs semantics.  The information at some level, systemically, 
is bound to the machine.

So we have: (forgiveSimplification)

o  Event Parsing:  SAX, event-oriented, tag-stacker, system driven by 
pure names.

o  Object-oriented:  DOM, instantiate the property set as a tree of 
objects with interfaces

That works fine.  Why not?  The purpose of structured information is 
to bind it and share it among cooperative entities where cooperation 
is defined as the transactions among defined boundaries, cooperation 
by the framework of interfaces shared.   The Browser doesn't care.  
It see this all as services.  That's fine.  Good design.

> I mentioned the DOM only as an *example* of ready-to-run objects; I
> did not intend to say that the DOM is useful for every purpose.

Right.  DOM is good when you need an object in memory to talk to.
SAX is good when you need an object in memory to talk to you.

> Ready-to-run objects (including your indexes) are ready-to-run
> objects, regardless of the process by which they were created.

But not by the definition of the interface.  To use the definition, 
at least at the IDL, you need a schematic representation of the
interface. 
How do I know they are <readyToRun>?  Where in the markup do I find this 
<readyToRun> tag?  (ok... yep, messages in markup, right?)  DNA?

> Ready-to-run objects (whatever one may call them, and regardless of
> how they are implemented) are manufactured by all applications of XML,
> not just by some of them.

Sure.  That's the beauty of it.  Pick any good object, relational, 
stringMachine system and it still works.   The hard problem is 
when the machines are through with it, does it still mean the 
same thing?  Can we prove it?

Does that matter if practice reveals we don't always have to 
be able to prove it?  We have to be able to prove it often 
enough and in enough formats that the maps in the right 
places don't become incoherent.

I was reading the Cocoon papers and the notion of "hot spots" 
is perfect because the optimization is by the frequency of 
use.  Good metaphor.  Some may want to look up some DARPA work 
from the early eighties (DICE project) on the application 
of the model of simulated annealing.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 01:39:17 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:29 2004
Subject: Do SGML and XML co-exist?
References: <199911221015.CAA09972@boethius.eng.sun.com>
Message-ID: <3839EA3D.36B6@hiwaay.net>

Jon Bosak wrote:
> 
> Len is no doubt referring to the gimmick of tossing a copy of the
> 30-page XML spec into the first rows of an SGML audience without
> killing anyone.  Credit for this wonderful piece of theater belongs to
> Tim Bray, not me.

Good show, good performance.  Is it so?  XML is big and getting bigger. 
Yet, this is by application expansion, not expansion of XML 1.0, so, the 
answer is Yes, it is. 

> | Personally, I give credit to Yuri Rubinsky, President of SoftQuad
> | until his untimely death, to the birth of XML.
> 
> Me too.  He was obviously heading in this direction with SoftQuad
> Panorama and his efforts to engage the Web community with "SGML on the
> Web".  I would never have taken up the torch if Yuri had lived; I
> would simply have kept following him.  I have felt throughout the XML
> effort that I have just been trying to realize Yuri's vision.

I loved Yuri.  He was a good man.  He had his business and 
he kept that on a track that both benefitted SGML and his business.
He was not a saint.  He was an excellent diplomat across language 
boundaries, communities that were both sensitive and hungry. 
Communities 
need leaders.  Yuri found the talent and dedicated his life to it.  
Yuri always knew that it was people and SGML, not one or the other. 
He knew what the stakes were.  He understood the importance of it. 

Big shoes to fill.  You've done well, Jon.
 
> In general, I don't worry that the pioneers will be forgetten in the
> end.  Eventually the historians will catch up with this and we shall
> all just become footnotes in someone's doctoral dissertation.  Credit
> will be given where it's due.

Some.  Credit is a funny thing.  It takes a lot of effort 
to find the credit among the records unless those that see opine.   
Individuals count.  History is just history.  The tale of community 
is a tale of the names and adventures of people.   

XML is language.   The hand that touches is real.

Contracts are made among people.  That is all.  SGML, XML, 
SML, these are just names we give to things we conceive. 
The power is in the agreement.  The power is in the community.

I like Apache.  Good show! Good show!

> But I agree that it would be hard to understand Yuri's impact without
> having seen him in action.

No it won't.  We are his friends.  We tell them. 

o  Charles made it.  Yuri sold it.  It was cool.

o  Next?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 03:03:08 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:29 2004
Subject: SGML, XML and SML
References: <000d01bf3523$5a51c8e0$099918d1@docuverse1>
Message-ID: <026b01bf355f$4635a7f0$eb020a0a@bowstreet.com>

> No.  SML has no concept of documents.  Every SML data is a
> external parsed XML entity.

But an external parsed XML entity can pass for an XML document if it has
only a single top-level element.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Tue Nov 23 03:01:53 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:29 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E9092@sohos002.ied-support.net>
Message-ID: <NBBBJPGDLPIHJGEHAKBAIEFDEHAA.martind@netfolder.com>

Hi Mark,

Didier PH Martin wrote:
> Didier reply:
> Yes mark, if we got the notion of scope for rendition it
> would be a lot
> easier to assemble fragment/documents into a whole. Obviously, each
> assembled part would have to take into account that it is
> included in a
> whole for rendition (i.e like an HTML+CSS document for
> example).

Mark said:
I wouldn't impose such a limitation myself. Why should the fragment
'know' anything about its container? (If I understand you correctly -
and apologies if I don't.) Provided it has its namespace declaration
then it can in theory exist in any container that will have it.

Didier reply:
It didn't meant that the fragment has to be semantically aware of the
container but more that the associated style sheet (the style sheet
associated to the fragment) has to be aware of the global context. For
instance, will only provide rendition instructions for the fragment.

Mark said:
In fact, with RDF you could just wrap some XML in a CDATA tag and bung
it in a description. Or you can place it in a BizTalk 'envelope', or you
can use MIME, or even package it up with headers and send it through
HTTP/WebDAV. Each of these has different notions of validity. RDF or
BizTalk (or XML Fragment Interchange) require that the containing
document is well-formed XML with its contained object(s). But a
PROPPATCH in WebDAV requires that the containing document is well-formed
HTTP (plus a bit), and the document describing the elements being
patched are well-formed XML. So we have different notions of
'correctness' with different transports.

So, we have the notion of a document that we need to transport, and it
has its own requirements as to well-formedness, validity, etc. And then
we have the transport mechanism which has its own means of communicating
errors, etc.. And in some situations XML will be used as the transport
mechanism - as with BizTalk - but I don't think it should logically be
treated any different to other transport mechanisms. (Of course it's
handy to have it as XML because we can use all our other tools to handle
transport.)

Didier reply:
I agree

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Tue Nov 23 03:06:13 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:29 2004
Subject: XML One expert panel now playing on TechNetCast
References: <NBBBJPGDLPIHJGEHAKBAAEFDEHAA.martind@netfolder.com>
Message-ID: <002f01bf355f$ffcc2f40$0b00a8c0@grissom>

Use this URL:

www.technetcast.com

if you need to download RealPlayer before playing the audio. It's a free
download.

Otherwise, you can go to this URL, click on play, and select an audio
playback option (MP3,
Real Player, download).

http://www.technetcast.com/tnc_program.html?program_id=59




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



From gtn at ebt.com  Tue Nov 23 03:29:02 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:29 2004
Subject: What do XML consultants actually do?
In-Reply-To: <m3emdiod0u.fsf@localhost.localdomain>
Message-ID: <001301bf3562$5f8349d0$dc7370c6@ebt.com>

> God!  If I were paid to help people figure out XML syntax, I would be
> way, way, way, WAY overpaid.  What companies hire consultants for is
> to help them understand how to exchange and process information: 90%
> of the complexity comes from the nature of the information they're
> trying to model and the business environment in which they work, 9.9%
> of the complexity comes from finding, learning, and integrating the
> software components, and perhaps the remaining 0.1% has something to
> do with the syntax of the markup layer (but probably not).

Absolutely. I've seen a number of project fail from incomplete 
understanding of the problem domain, and none from incomplete
understanding of the syntax.

Again, the complexity isn't in XML... it's in the problems being
solved. 

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



From gtn at ebt.com  Tue Nov 23 03:29:00 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:29 2004
Subject: Feeling good about SML
In-Reply-To: <3838DE2D.2BC1646D@pacbell.net>
Message-ID: <001201bf3562$5e705330$dc7370c6@ebt.com>

> As folk have pointed out, pointy brackets aren't 
> "fundamentally necessary" and LISP S-Expressions are
> _at least_ as powerful ... with a much richer
> and more powerful set of programming systems and traditions 
> behind them.

Yes... I gave this example in a seminar recently, and that comes
directly from my experience implementing a distributed hypermedia
system that used s-expressions for generic markup.

> So a "fundamentally necessary" argument is not at all 
> convincing to me.

Not to me either.


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



From rev-bob at gotc.com  Tue Nov 23 03:47:29 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:29 2004
Subject: SGML, XML and SML
Message-ID: <199911222247579.SM01008@Unknown.>

> ** Original Sender: David Megginson <david@megginson.com>
>
> Of course, I've been wrong often before, and I'm not an expert in
> small or embedded devices, so I'll look forward to seeing what
> happens.  I do think that small devices will be at the centre of
> computing in the next decade (and a mostly MS-free centre, to boot).
> I'm also looking forward to the big 3COM antitrust trial in 2009.

Okay, this may qualify as high heresy these days, but someone has to say it...and it looks 
like the duty falls to me.  The fact is, I *despise* palmtops when it comes to documents 
bigger than, say, your average shopping list.  It's not an implementation issue (ie. "the 
technology isn't mature enough"); it's a usability issue.  For documents of a reasonable 
size (greater than 1K or so), a palmtop is just too small to make adequate use of them; 
you just can't see enough of the document at once to easily follow it.  Lists and such 
work fine, but even for such "trivial" tasks as email, I wouldn't dream of trying to cram 
an application or even an interface for one into a small device.  Certain implementation 
issues also come into play - for instance, it's a trivial task to write a document  on a 
keyboard, but rather arduous when you're scribbling on a PDA - but by and large, it's a 
mindspace issue.

How does this relate to the current topic?  Well, except for a couple of applications 
(stock quotes come to mind), I consider the much-hyped Wireless Web to be slightly less 
torturous than an iron maiden (and I *don't* mean the rock group).  The one thing I can 
think of which would show real promise in changing this is exactly the one thing nobody 
really seems to be looking at - text-to-speech conversion for small devices.  That is, 
instead of working on making the tiny screens a little bit bigger or a little bit clearer, 
maybe someone could work on routing the information through a speaker and only 
having the screen as a reference point for data which is hard to understand through 
audio.  I hear a lot - especially here - about the "how" of fitting XML onto cellphones 
and palmtops; what I haven't heard anything about yet is the "why" of it.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kragen at pobox.com  Tue Nov 23 04:12:12 1999
From: kragen at pobox.com (Kragen Sitaker)
Date: Mon Jun  7 17:17:29 2004
Subject: What do XML consultants actually do?
Message-ID: <Pine.GSO.4.10.9911222238540.4442-100000@kirk.dnaco.net>

David Megginson writes (of a proposed simplified XML):
> God!  If I were paid to help people figure out XML syntax, I would be
> way, way, way, WAY overpaid.  What companies hire consultants for is
> to help them understand how to exchange and process information: 90%
> of the complexity comes from the nature of the information they're
> trying to model and the business environment in which they work, 9.9%
> of the complexity comes from finding, learning, and integrating the
> software components, and perhaps the remaining 0.1% has something to
> do with the syntax of the markup layer (but probably not).

So in a $1 million project, perhaps $1,000 of the effort goes to things
like implementing DTDs, verifying that input is in the correct form,
fixing bugs in outputting XML, etc.?  Sounds reasonable, if perhaps a
little low.  But maybe the projects you're working on are much bigger
and harder than the ones I'm familiar with.  In fact, that seems quite
likely.

I suggest that the most important projects are the small ones.
ArborText is undoubtedly tremendously significant, and no doubt the
syntax of SGML contributes very little to its complexity.  But the
significance of Arbortext is outweighed by the hundreds of little XML
programs people have hacked up -- programs that would never have been
attempted if understanding SGML were a prerequisite.

Procter & Gamble makes more money than Giddings & Lewis[0] -- fifty
times as much, in fact -- and directly benefits thousands of times as
many people with its products, despite G&L's products arguably
providing much more benefit per dollar.  This is because the commitment
required to profit from P&G's products is trivial, so more people do
it.  You don't need to know anything and you don't need to spend any
significant amount of money.

(Maybe someone else can come up with a better comparison; P&G vs. G&L
is about as apples-and-oranges as it gets.)


[0] Actually, they apparently got bought out by "TAQU" in 1997, after
    losing money.  I'm comparing P&G's 1998 revenues with G&L's 1996
    revenues.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 04:13:50 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:17:29 2004
Subject: SGML, XML and SML
References: <199911222247579.SM01008@Unknown.>
Message-ID: <383A144E.12B7C22C@infinet.com>

rev-bob@gotc.com wrote:

> > ** Original Sender: David Megginson <david@megginson.com>
> >
> > Of course, I've been wrong often before, and I'm not an expert in
> > small or embedded devices, so I'll look forward to seeing what
> > happens.  I do think that small devices will be at the centre of
> > computing in the next decade (and a mostly MS-free centre, to boot).
> > I'm also looking forward to the big 3COM antitrust trial in 2009.
>
> Okay, this may qualify as high heresy these days, but someone has to say it...and it looks
> like the duty falls to me.  The fact is, I *despise* palmtops when it comes to documents
> bigger than, say, your average shopping list.  It's not an implementation issue (ie. "the
> technology isn't mature enough"); it's a usability issue.  For documents of a reasonable
> size (greater than 1K or so), a palmtop is just too small to make adequate use of them;
> you just can't see enough of the document at once to easily follow it.  Lists and such
> work fine, but even for such "trivial" tasks as email, I wouldn't dream of trying to cram
> an application or even an interface for one into a small device.  Certain implementation
> issues also come into play - for instance, it's a trivial task to write a document  on a
> keyboard, but rather arduous when you're scribbling on a PDA - but by and large, it's a
> mindspace issue.
>
> How does this relate to the current topic?  Well, except for a couple of applications
> (stock quotes come to mind), I consider the much-hyped Wireless Web to be slightly less
> torturous than an iron maiden (and I *don't* mean the rock group).  The one thing I can
> think of which would show real promise in changing this is exactly the one thing nobody
> really seems to be looking at - text-to-speech conversion for small devices.  That is,
> instead of working on making the tiny screens a little bit bigger or a little bit clearer,
> maybe someone could work on routing the information through a speaker and only
> having the screen as a reference point for data which is hard to understand through
> audio.  I hear a lot - especially here - about the "how" of fitting XML onto cellphones
> and palmtops; what I haven't heard anything about yet is the "why" of it.

I agree completely. I am trying to understand how everyone and their brother thinks this
"embedded market" will overtake PC's anytime soon when no one has created a display device or
user interface that is significantly better than the old TRS-80. Perhaps until we have some
way or bending light in creative ways that creates holograms of the document view, we will
never have anything really that useful to do with Palm Pilots or net-enabled toasters other
than the least common denominator uses we have today which are 10 character length email and a
few stock quotes popped onto your screen. The same people who said the "PC is dead" a couple
of years ago and promoted the NC, are the same simple minded people that think these so called
"embedded devices" will replace the PC. Yes it is true yesterdays PC quality chips are now
running Palm Pilots and other PDA's, but the real problem of creating miniature display
devices that show more than 3 characters and input devices that don't give you carpal tunnel
is another story.

In other words, I could have a supercomputer in my Palm Pilot, but what would that buy me if I
have no feasible way of interracting with that supercomputer. I suppose I could try and crunch
N digits of pi for the fun of it, but I do not exactly consider this useful for doing word
processing or spreadsheets, or anything but the most trivial applications.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 04:22:34 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
Message-ID: <3.0.32.19991122202035.013167a0@pop.intergate.ca>

At 10:50 PM 11/22/99 -0500, rev-bob@gotc.com wrote:
>The fact is, I *despise* palmtops when it comes to documents 
>bigger than, say, your average shopping list.  

I'm with the Rev, and you know what, so is history.  In my
embarrassingly lengthy career in this biz, I've seen the rise
and subsequent fall of database computers, lisp computers,
network computers, massively parallel computers, etc etc
ad nauseam.  The most generic general-purpose Von Neumann machine
always wins at the end of the day.  The easy-to-understand reason
is that that's where the big R&D bucks are being spent.  But maybe
there's something deeper.

Hey, I'm as Palm-Pilot-addicted as the next geek.  But I have yet
to see anything that I can stick in my pocket that has any chance
of replacing aforesaid general-purpose computer.   IMHO, the Toshiba
Portege series (or equivalent) has the perfect form-factor; large
enough to touch-type and see a few windows, small enough to go
in the puniest briefcase.  And still a general-purpose VonN box.

 -T.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 05:57:48 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
Message-ID: <002e01bf357b$29f6e880$0ef96d8c@NT.JELLIFFE.COM.AU>


From: Paul Tchistopolskii <paul@qub.com

>1. Why entities should live in the core, if one can use
>any macroprocessor to get  *more*  flexible functionality?

1) So that I can reference entities in attribute values
2) So that I can have all my URIs in a header at the top,
for maintainability
3) Because I am not using UNIX pipes: is there a java
version of M4?
4) Because if I want to, I can already use a preprocessor;
removing entities does not increase my options;
5) Because no macro preprocessors are internationalized;
6) Because entities allow tracking of file and line-number:
if a macro package does this and it is implemented using
pipes then there must be some kind of PI or conventional
comment embedded (I guess Don and the Elementalists would
want this to be an element which a post-processor would
then hide!)

>2. How often do we need entities outside the DTD's ?

Often.

>> I suspect CDATA sections are hard to live
>> without if you're writing XML documents about HTML or XML, though.

Or any time you are writing programming code that uses <, & or >

>Let us have <CDATA> element ? I think up to 3-5 elements with
>'hardcoded' semantics will not cause a big problem.

So the parent element of data changes depending on which way the
person has marked the data up?   I suppose that in DOM & XPath
"parent" will become useless; instead it would be "first ancestor that
is not a CDATA element".

This is the same problem that open
content models give: with open content models, the "previousSibling"
and "nextSibling" elements are not so useful (and, indeed, "firstChild"
and "lastChild") because we cannot be sure what they are without
checking.  But that is a small cost.  However, moving us from a
"parent" to a "virtualParent" relationship would be quite a major
change.

>It's why I think that SML vs XML is very similiar to
>XML vs SGML.
>
>At some point it would be easier to break the
>compatibility than to support legacy. As far as I
>understand, exactly that thing happened with
>XML vs SGML.

No, SGML was enhanced to allow XML.  (By the way, I think
WebSGML already allows SML: I think it is legit to
map the MDO and PIO delimiter to some "shunned
characters" for example. The only difficulty is if multiple
headers are involved.)

SGML was based on the
idea that it is impossible to get agreement on lexical
issues from everyone, so the important issue is that
different requirements can be described formally/legally.
So XML did not break compatability with the standard;
but no-one has ever thought that all SGML products
should support all possible SGML syntaxes (despite James
Clarks heroic efforts).

XML is interesting not because it is simpler (my first
simplified-SGML text-processing system was more than
10 years ago) but because there is *agreement*.  That
has been the new thing.

I think this list will contain many old SGML hacks who
will be dissapointed but not surprised if eventually
XML fragments.
---
By the way, I missed sending this before: it gives the
cannonical XML productions with an guess at SML
productions: they are the same size. (And, if we take
out namespaces from one, we can take them out
from the other, so no effective difference.)

The current canonical XML grammar is this:
[1]    canonXML    ::=    (PI #xA)* element #xA (PI #xA)*
[2]    element    ::=    Stag (Datachar | element | PI)* Etag
[3]    Stag    ::=    '<' Name NSDecl? (Att NSDecl?)* '>'
[4]    Etag    ::=    '</' Name '>'
[5]    NSDecl    ::=    #x20 'xmlns:' Prefix '=' '"' Attvalchar* '"'
[6]    Att    ::=    #x20 Name '=' '"' Attvalchar* '"'
[7]    Datachar    ::=    '&amp;' | '&lt;' | '&gt;' | '&#xD;'
   | (Char - ('&' | '<' | '>' | #xD ))
[8]    Attvalchar    ::=    '&amp;' | '&lt;' | '&quot;' | '&#x9;' |
'&#xA;' | '&#xD;'
   | (Char - ('&' | '<' | '"' | #x9 | #xA | #xD))
[9]    Name    ::=    (Prefix ':')? NCName
[10]    Prefix    ::=    'n' [1-9] [0-9]*
[11]    PI    ::=    '<?' PITarget (#x20 (Char+ - (Char* '?>' Char*)))?
'?>'
[12]    PITarget    ::=    NCName - (('X' | 'x') ('M' | 'm') ('L' |
'l'))

which is hardly complex. Presumably, your SML would be
something like this

[1]    canonXML    ::=    (Comment | #xA)*  element (Comment | #xA)*
[2]    element    ::=   ( Stag (Datachar | element  | Comment )* Etag )
| Mtag
[3]    Stag    ::=    '<' Name NSDecl? (Att NSDecl?)* '>'
[4]    Etag    ::=    '</' Name '>'
[5]    NSDecl    ::=    #x20 'xmlns:' Prefix '=' '"' Attvalchar* '"'
[6]    Att    ::=    #x20 Name '=' '"' Attvalchar* '"'
[7]    Datachar    ::=    '&amp;' | '&lt;' | '&gt;' | (Char - ('&' | '<'
| '>' | #x9 | #xA | | #xD ))
[8]    Attvalchar    ::=    '&amp;' | '&lt;' | '&quot;'  | (Char - ('&'
| '<' | '"' | #x9 | #xA | #xD))
[9]    Name    ::=    (Prefix ':')? NCName
[10]    Prefix    ::=    'n' [1-9] [0-9]*
[11]    Comment   ::=    '<!--' (Char+ - (Char* '-->')))? '-->'
[12 ]  Mtag   ::=    '<' Name NSDecl? (Att NSDecl?)* '/>'

Which is the same level of complexity. You take out PIs and
add comments and empty start tags.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 06:13:21 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:30 2004
Subject: How to keep  "useless" information with SAX (2?).
Message-ID: <026e01bf3579$7f8e2440$5df5c13f@PaulTchistopolskii>


Hello.

I'm playing with projectX ( SAX 1.0 based) code, 
trying to force SAX API to read the XML document 
and then to save it *unchanged*.

I was having some problems with 
'useless whitespace' outside the elements.  

I mean the situation, when I have:

<!DOCTYPE content SYSTEM "content.dtd">
<!-- some comment -->
<root>
</root>

With Sun's extensions to SAX API I could get 
the content of <!DOCTYPE and the content of comment.

Unfortunately, whitespace ( including the 
newline) between those constructions has been 
lost.

What I did to workaround this problem was 
patching the code in one place:

/com/sun/xml/parser/Parser.java

 private boolean maybeWhitespace () throws IOException, SAXException
 {

 if (!(inExternalPE && doLexicalPE))
  return in.ignorableWhitespace (docHandler);  

 // return in.maybeWhitespace ();    -- this was the old code

This allows me to get "ignoreable whitespace" 
everywhere, but not only  inside the elements, 
using ignoreableWhitespace callback. 

However - I feel that I'm making some ugly thing, 
because for some reason ignoreableWhitespace is 
defined only for element's content.

I'm wondering, what was the idea behind tracking 
ignoreableWhitespace only inside the elements ?

What happens in SAX2 ?

It also appears that Sun's parser ( I think that 
Sun's parser is not the exeption, right?) does not care 
about some 'useless' things, like <?xml header.

I mean that accodring to the code there is simply 
to way to capture the content of the <?xml header, even 
it may have some *very*  interesting ( sometimes 
critical ) information, like encoding. 

Because I already saw poor people, providing 
"windows-something", and because of some 
Java-specific issues, the current point of view 
on <?xml  header  (something not useful enough 
to keep) looks strange.

What happens in SAX2 ?

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 07:55:27 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
References: <002e01bf357b$29f6e880$0ef96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <02b001bf3588$39e81a40$5df5c13f@PaulTchistopolskii>


> From: Paul Tchistopolskii <paul@qub.com
> 
> >1. Why entities should live in the core, if one can use
> >any macroprocessor to get  *more*  flexible functionality?
> 
> 1) So that I can reference entities in attribute values

I'm talking about SML. ;-) No attributes there ( I think ).
Anyway - you can do it with m4.

> 2) So that I can have all my URIs in a header at the top,
> for maintainability

m4

> 3) Because I am not using UNIX pipes: is there a java
> version of M4?

You could wrap m4 with JNI. 1 day task, I think.

> 4) Because if I want to, I can already use a preprocessor;
> removing entities does not increase my options;

Why SGML has been stripped to XML? It does not 
increazed any  options ....

> 5) Because no macro preprocessors are internationalized;

Oh... I was also thinking that XML is internationalized. 
Until I tried ( occasionaly) to invoke Expat on some file 
with <?xml encoding="windows-something">. 
It appears that it may be  better to talk about 
Java-internationalized XML and MS-internationalized XML ?

> 6) Because entities allow tracking of file and line-number:
> if a macro package does this and it is implemented using
> pipes then there must be some kind of PI or conventional
> comment embedded (I guess Don and the Elementalists would
> want this to be an element which a post-processor would
> then hide!)

I agree,  it is sometimes inconvinient to use 
macroprocessing. However, I think that because 
most of users are *not* using macroprocessing 
anyway, they'l not notice that entities has been 
gone. ;-)

Also,  one can use belowed XML macroprocessor on server-side
( together with belowed weak DTD-based validation), but 
should all that code go to the client ? 

I already  know people who are writing simplified  XML parsers 
( right now ;-) to fit into some hardware.  There  is no 
validation, no entities and ... well ... they  have hacked together 
something very close to SML ;-)

Next step for them will be to write simplified XT, DOM e t.c. 

As far as I remember - there will be always some device with 
'small' memory.  For last 10 years I'm moving from 2-16-32K to 
Megabytes and then back to Kilobytes again ;-) 

I don't know why it happens, I'l better to consider it to be 
some rule.
 
> >2. How often do we need entities outside the DTD's ?
> 
> Often.

Big question. For example, when placing bigger and bigger 
load on  XT,  macroses become templates , so  it could result
in plain XML and heavy stylesheet.  Macroses give us nothing 
with the database. Stylesheets give a lot.

I guess macroprocessing was so important  to SGML
because of  manual editing of many documents, long 
time ago. Right ? 
 
Actualy, macroprocessor looks like not a  good thing 
when it  comes to dataflow. C++ tried to avoid 
macroprocessing as a bad practice.  

Having 'internal' macroprocessor  is ... maybe nice ... 
but suspicious ( even I like macroprocessing itself,  
I prefer not to overuse it.)  I don't  think it should live 
in the core, because it's something 'extra'.  'Optional'.

I think it's the issue of taste.

> >> I suspect CDATA sections are hard to live
> >> without if you're writing XML documents about HTML or XML, though.
> 
> Or any time you are writing programming code that uses <, & or >
> 
> >Let us have <CDATA> element ? I think up to 3-5 elements with
> >'hardcoded' semantics will not cause a big problem.
> 
> So the parent element of data changes depending on which way the
> person has marked the data up?   I suppose that in DOM & XPath
> "parent" will become useless; instead it would be "first ancestor that
> is not a CDATA element".

Perfect.  I'm glad I already agree to remove CDATA  from  SML  - 
there is something to think about. 
 
> This is the same problem that open
> content models give: with open content models, the "previousSibling"
> and "nextSibling" elements are not so useful (and, indeed, "firstChild"
> and "lastChild") because we cannot be sure what they are without
> checking.  But that is a small cost.  However, moving us from a
> "parent" to a "virtualParent" relationship would be quite a major
> change.

I agree - it is not easy to find the workaround. It's better to drop 
CDATA ;-)

> >It's why I think that SML vs XML is very similiar to
> >XML vs SGML.
> >
> >At some point it would be easier to break the
> >compatibility than to support legacy. As far as I
> >understand, exactly that thing happened with
> >XML vs SGML.
> 
> No, SGML was enhanced to allow XML.  (By the way, I think
> WebSGML already allows SML: I think it is legit to
> map the MDO and PIO delimiter to some "shunned
> characters" for example. The only difficulty is if multiple
> headers are involved.)

> SGML was based on the
> idea that it is impossible to get agreement on lexical
> issues from everyone, so the important issue is that
> different requirements can be described formally/legally.
> So XML did not break compatability with the standard;
> but no-one has ever thought that all SGML products
> should support all possible SGML syntaxes (despite James
> Clarks heroic efforts).
> 
> XML is interesting not because it is simpler (my first
> simplified-SGML text-processing system was more than
> 10 years ago) but because there is *agreement*.  That
> has been the new thing.

Oh ... It's something I can not understand ...   
It's too complex  for me...

The only reason  why I supported the idea of SML 
was that 2 weeks ago I just had a couple of long 
discussions  with one real-life client.  

As a result I realized that they are reimplementing 
almost *every*part* of XML standard, because 
existing XML framework  is  too 'bloated' for them.  

So when I saw the SML posting - I provided some 
thoughts I got after that discussion. The thoughts 
are: there is some place for SML.  

How big is it ?

I don't know.

Is XML good? Of course it is. Is it 'bloated' .... well ... 
I don't know.  It's the issue of taste.

It *could* be considered to be bloated.
 
> I think this list will contain many old SGML hacks who
> will be dissapointed but not surprised if eventually
> XML fragments.
> ---
> By the way, I missed sending this before: it gives the
> cannonical XML productions with an guess at SML
> productions: they are the same size. (And, if we take
> out namespaces from one, we can take them out
> from the other, so no effective difference.)
> 
> The current canonical XML grammar is this:
> [1]    canonXML    ::=    (PI #xA)* element #xA (PI #xA)*
> [2]    element    ::=    Stag (Datachar | element | PI)* Etag
> [3]    Stag    ::=    '<' Name NSDecl? (Att NSDecl?)* '>'
> [4]    Etag    ::=    '</' Name '>'
> [5]    NSDecl    ::=    #x20 'xmlns:' Prefix '=' '"' Attvalchar* '"'
> [6]    Att    ::=    #x20 Name '=' '"' Attvalchar* '"'
> [7]    Datachar    ::=    '&amp;' | '&lt;' | '&gt;' | '&#xD;'
>    | (Char - ('&' | '<' | '>' | #xD ))
> [8]    Attvalchar    ::=    '&amp;' | '&lt;' | '&quot;' | '&#x9;' |
> '&#xA;' | '&#xD;'
>    | (Char - ('&' | '<' | '"' | #x9 | #xA | #xD))
> [9]    Name    ::=    (Prefix ':')? NCName
> [10]    Prefix    ::=    'n' [1-9] [0-9]*
> [11]    PI    ::=    '<?' PITarget (#x20 (Char+ - (Char* '?>' Char*)))?
> '?>'
> [12]    PITarget    ::=    NCName - (('X' | 'x') ('M' | 'm') ('L' |
> 'l'))
> 
> which is hardly complex. Presumably, your SML would be
> something like this
> 
> [1]    canonXML    ::=    (Comment | #xA)*  element (Comment | #xA)*
> [2]    element    ::=   ( Stag (Datachar | element  | Comment )* Etag )
> | Mtag
> [3]    Stag    ::=    '<' Name NSDecl? (Att NSDecl?)* '>'
> [4]    Etag    ::=    '</' Name '>'
> [5]    NSDecl    ::=    #x20 'xmlns:' Prefix '=' '"' Attvalchar* '"'
> [6]    Att    ::=    #x20 Name '=' '"' Attvalchar* '"'
> [7]    Datachar    ::=    '&amp;' | '&lt;' | '&gt;' | (Char - ('&' | '<'
> | '>' | #x9 | #xA | | #xD ))
> [8]    Attvalchar    ::=    '&amp;' | '&lt;' | '&quot;'  | (Char - ('&'
> | '<' | '"' | #x9 | #xA | #xD))
> [9]    Name    ::=    (Prefix ':')? NCName
> [10]    Prefix    ::=    'n' [1-9] [0-9]*
> [11]    Comment   ::=    '<!--' (Char+ - (Char* '-->')))? '-->'
> [12 ]  Mtag   ::=    '<' Name NSDecl? (Att NSDecl?)* '/>'
> 
> Which is the same level of complexity. You take out PIs and
> add comments and empty start tags.

As far as I understand,  SML has no attributes ... And also 
maybe no MTag ...  rules are simpler ...  I suggest  
"take no prisoners" :

+  Stag and Etag 
+  Datachar

+  Comment ( optional )
+  Mtag for empty element ( optional )

I feel very suspicious when I see some project  that 
could not be implemented by one 'ideal' developer. 

All the programs I love - could be implemented by 
one developer ( to the shape of  reasonable prototype) . 

Implementing the XML framework to get something 
handy looks like a *huge*  task. Implementing reasonable 
SML framework looks doable.

Rgds.Paul.





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.davidson at eng.sun.com  Tue Nov 23 08:15:07 1999
From: james.davidson at eng.sun.com (James Duncan Davidson)
Date: Mon Jun  7 17:17:30 2004
Subject: [ANNOUNCE] JAXP Specification v1.0 Public Draft 1
Message-ID: <383A4FFE.E6F7A49B@eng.sun.com>

The Java(tm) API for XML Parsing Specification v1.0 has now been
released as Public Draft 1.

The Java API for XML Parsing (JAXP) Optional Package provides basic
functionality for reading, manipulating, and generating XML documents
through pure Java APIs. This API optional package provides a standard
way for any XML-conformant parser to be accessed by an application. The
reference implementation uses the high performance Java Project X as its
default XML parser. However, the software's pluggable architecture
allows any XML conformant parser to be used.

Public Review is a critical part of the development process. It's your
chance to review the specification and comment directly to the expert
group that created it.

To download the specification and for more information, see:

        http://java.sun.com/xml/

To read more about the Java Community Process and what it means for a
specification to be in "Public Draft", see:

        http://java.sun.com/aboutJava/communityprocess/

Please send all comments about this specification to:

        xml-spec-comments@eng.sun.com


-- 
James Davidson                                     duncan@eng.sun.com 
Java + XML / Portable Code + Portable Data                 !try; do()

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 08:23:56 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:30 2004
Subject: facts, conclusions, and exhortations re XML (long)
References: <199911210111.TAA00461@bruno.techno.com>
Message-ID: <3839E823.2E2E6391@prescod.net>

"Steven R. Newcomb" wrote:
> 
> ...
> The potential benefit
> of XML is that it will allow any *knowledge* to be transferred by
> anyone to anyone else.  That can only happen under one of two
> circumstances:
> 
> * if the protocols and services that enable knowledge transfer are
>   commoditized (virtually all people who love the Web prefer this
>   possibility), or
> 
> * if all the important protocols and services are totally controlled
>   by a worldwide de facto monopoly (Microsoft prefers this
>   possibility, as long as the monopoly belongs to Microsoft).

Or else we could continue to muddle along with a mix of proprietary and
open standards and protocols as we have for decades and probably will
for decades to come. 

> I ran across more evidence of Microsoft's anticompetitive behavior
> recently.  Most of you probably already knew about it.  XPath, as
> implemented by Microsoft, provides access to the first node of any
> nodelist as the zeroeth node (the node in the list that is addressed
> by an array index value of 0), while the relevant W3C draft requires
> it to be the first (index value of 1) node.  

Some relevant facts:

 1. Early versions of Microsoft's XML parser expected an upper case XML
declaration and allowed a minimized </> end-tag syntax (which I rather
liked). When XML 1.0 was finalized they fixed their parser to conform to
it. IE5 disallows both practices by default. Those conventions have thus
fallen into disuse.

 2. Early versions of Microsoft's XSL engine used a totally different
syntax: NOTE-XSL. But IE5 used a syntax similar to (but not identical
to) the draft that was available when IE5 shipped. AFAIK, NOTE-XSL does
not work anymore and the dozens of NOTE-XSL stylesheets in existence
have fallen into obsolecence.

 3. IE5 claims to support XML-Data but the subset that it supports is so
anemic that one presumes that Microsoft is really very half-hearted
about the entire effort.

 4. Hardly anybody uses IE5 client-side stylesheet for production work.
To start with, no serious web publisher can afford to alienate the vast
majority of users using non-IE5 client software. 

Microsoft labels these features "technology previews." They know that
some stupid people will build real systems on them but they say, quite
rightly, that those systems will break with new versions of the tools
and those people "get what they deserve." If it were Netscape issuing
these technology previews we would laud them for testing out new ideas
and providing feedback to the standards process (which Microsoft DOES
DO).

Let's give credit where it is due. The practice of shipping "technology
previews" has benefits and costs but Microsoft's history indicates that
they move to the real specifications when they become available.
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
It's such a 
Bore
Being always
Poor
LANGSTON HUGHES
http://www.northshore.net/homepages/hope/engHughes.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 08:23:23 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk>
Message-ID: <38399EAD.58EB4FDE@prescod.net>

Dan Brickley wrote:
> 
> I was being slightly tongue-in-cheek, but the combination of Paul
> Prescod's msg (which I replied to) and previous SML advocacy seemed to
> be heading in this direction. In other words, that for many
> data-oriented applications, XML's document-oriented heritage makes it
> sometimes challenging to use. I'm far from convinced that a return to
> s-expressions, or the creation of a trivial subset (SML), would be
> useful right now. There are enough X** specifications and applications
> around already to make it a nightmare for non XML-obsessed developers
> trying to figure out how the various piecese of the puzzle
> inter-relate. Inventing a new subset syntax would make it even hard to
> present a coherent picture...

Well they are two different proposals with different (even opposite!)
strengths and weaknesses. Let's try it this way: RDF is hardly taking
over the world today. I claim that that confusion stems primarily from
several factors, but at least one of them is syntax.

The syntax is brutally complex because it reintroduces minimization
hacks like the ones XML took out of SGML. Without the minimization
hacks, the syntax is verbose and hard to read. RDF on SML would make
this problem worse, not better. Removing features from XML can't make
RDF's XML representation more natural. A new syntax, developed from
scratch could of course make RDF more natural.

Semantics:

 * why does a language for describing assertion DAGs have to be used for
"metadata"? does using it for something make that something "metadata"?

Interactions: 

 * what's the relationship with XLink...
 * ...XML Schemas...
 * ...XHTML Meta tags...



-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
It's such a 
Bore
Being always
Poor
LANGSTON HUGHES
http://www.northshore.net/homepages/hope/engHughes.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From kavita.t at MailAndNews.com  Tue Nov 23 08:49:15 1999
From: kavita.t at MailAndNews.com (Kavita)
Date: Mon Jun  7 17:17:30 2004
Subject: unsubscribe
Message-ID: <383B01A2@MailAndNews.com>

unsubscribe for <kavita.t@mailandnews.com>

------------------------------------------------------------
 Get your FREE web-based e-mail and newsgroup access at:
                http://MailAndNews.com

 Create a new mailbox, or access your existing IMAP4 or
 POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------


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



From crism at exemplary.net  Tue Nov 23 08:53:37 1999
From: crism at exemplary.net (Christopher R. Maden)
Date: Mon Jun  7 17:17:30 2004
Subject: Canonical XML (was: Re: SGML, XML and SML)
Message-ID: <v01530503b46003ee8e88@[209.157.134.45]>

[Rick Jelliffe]
>The current canonical XML grammar is this:
>[3]    Stag    ::=    '<' Name NSDecl? (Att NSDecl?)* '>'

Is that right?  So

   <foo xmlns:bar="" xmlns:baz="">

is illegal, but

   <foo xmlns:bar="" biz="" xmlns:baz="">

is legal?  That can't be right.  It seems it should be

   [3] Stag ::= '<' Name (Att | NSDecl)* '>'

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 09:11:15 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
In-Reply-To: <001701bf3542$ba4486b0$35d88dce@WORKGROUP>
Message-ID: <000501bf3592$ff8a1500$099918d1@docuverse1>

>Also, for that matter, one might argue that SML does not need
>CDATA sections because it has no notion of validity, or even a distinction
>between CDATA and PCDATA elements.  So long as the XML or HTML document
>being "quoted" is well formed, it can go inside any SML tag pair.  (Or am I
>missing something here?)

As for me, CDATA is out because it is a convenience feature
and a hack to boot.

'quoted' XML or HTML document can be placed inside
any SML tag pair or 'dumbed down' by escaping reserved
characters.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 09:11:19 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
In-Reply-To: <026b01bf355f$4635a7f0$eb020a0a@bowstreet.com>
Message-ID: <000601bf3593$00e2ee40$099918d1@docuverse1>

>> No.  SML has no concept of documents.  Every SML data is a
>> external parsed XML entity.
>
>But an external parsed XML entity can pass for an XML document 
>if it has only a single top-level element.

Absolutely.  The decision to have only a single top-level element
to match XML document production rule is entirely up to the
application.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 09:19:46 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
In-Reply-To: <002e01bf357b$29f6e880$0ef96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000801bf3594$28ce3da0$099918d1@docuverse1>

>which is hardly complex. Presumably, your SML would be
>something like this
>
>[1]    canonXML    ::=    (Comment | #xA)*  element (Comment | #xA)*
>[2]    element    ::=   ( Stag (Datachar | element  | Comment )* Etag )
>| Mtag
>[3]    Stag    ::=    '<' Name NSDecl? (Att NSDecl?)* '>'
>[4]    Etag    ::=    '</' Name '>'
>[5]    NSDecl    ::=    #x20 'xmlns:' Prefix '=' '"' Attvalchar* '"'
>[6]    Att    ::=    #x20 Name '=' '"' Attvalchar* '"'
>[7]    Datachar    ::=    '&amp;' | '&lt;' | '&gt;' | (Char -
>('&' | '<'
>| '>' | #x9 | #xA | | #xD ))
>[8]    Attvalchar    ::=    '&amp;' | '&lt;' | '&quot;'  | (Char - ('&'
>| '<' | '"' | #x9 | #xA | #xD))
>[9]    Name    ::=    (Prefix ':')? NCName
>[10]    Prefix    ::=    'n' [1-9] [0-9]*
>[11]    Comment   ::=    '<!--' (Char+ - (Char* '-->')))? '-->'
>[12 ]  Mtag   ::=    '<' Name NSDecl? (Att NSDecl?)* '/>'
>
>Which is the same level of complexity. You take out PIs and
>add comments and empty start tags.

No.  SML will be simpler even.  Remove comment and everything
related to namespace out.  Namespace is not supported at SML
level.  Assuming that attribute support is left in SML, SML can
work with the XML Namespace spec.

Best,

Don Park    -   mailto:donpark@docuverse.com
Docuverse   -   http://www.docuverse.com


>
>
>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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 09:26:52 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:30 2004
Subject: SGML, XML and SML
In-Reply-To: <3.0.32.19991122202035.013167a0@pop.intergate.ca>
Message-ID: <000901bf3595$14bea1a0$099918d1@docuverse1>

>>The fact is, I *despise* palmtops when it comes to documents 
>>bigger than, say, your average shopping list.

Palmtops will get slightly bigger display with much higher
resolution and color in the future which will greatly enhance
readability.  Note that most people have no problem reading
paperback novels which are just slightly bigger than Palmtops.

With better contrast and something like ClearType, you will
be amazed at the differences.  There is a lot of room for
improvement in the UI design as well.  What we have now
simply sucks less than before.  Handwriting recognition
will also improve drastically soon.  Some of the prototypes
I have seen is amazing.  The writing surface will also improve
to feel more like paper rather than feeling like skating over
thin ice.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From nisse at lysator.liu.se  Tue Nov 23 10:08:08 1999
From: nisse at lysator.liu.se (Niels Möller)
Date: Mon Jun  7 17:17:31 2004
Subject: XSLT Processors for C
Message-ID: <nnu2md1pxi.fsf@sanna.lysator.liu.se>

What XSLT processors exists out there, that I can use from C (or
perhaps C++)?

I could fork off a java machine and XP or LotusXSL, and parse its
output with expat. At least, that's the kind of functionality that I
would need. However, I would much prefer if I could get equivalent
functionality but avoid

  (i) external processes
  (ii) java machines
  (iii) real construction of the intermediate  XML document.

With (iii), I mean that it would be nice if the XSL processor doesn't
actually write the resultant XML document anywhere, but instead
provides me with SAX-like callbacks as the result-tree is constructed.

/Niels



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 12:08:07 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:31 2004
Subject: RDF, again
In-Reply-To: Paul Prescod's message of "Mon, 22 Nov 1999 20:51:10 +0100"
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net>
Message-ID: <m31z9ho1hg.fsf_-_@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> Let's try it this way: RDF is hardly taking over the world today. I
> claim that that confusion stems primarily from several factors, but
> at least one of them is syntax.

Well, RDF is making some progress behind the scenes, but it's hardly a
tidal wave, and I'd agree with Paul that the overly-complex syntax is
the biggest barrier.  The schema spec is nice and simple, though.

> The syntax is brutally complex because it reintroduces minimization
> hacks like the ones XML took out of SGML. 

Yes, that is very unfortunate.

> Without the minimization hacks, the syntax is verbose and hard to
> read.

That's inevitable for any kind of object exchange, though -- it's the
nature of the normalized object-oriented information.

Here's some mostly non-minimized RDF (using only the rdf:type as class
name):

  <foo:Person rdf:about="http://www.foo.com/ids/3645">
    <dc:title>Paul Prescod</dc:title>
    <foo:email>paul@prescod.net</foo:email>
    <foo:employer rdf:resource="http://www.foo.com/ids/0739"/>
  </foo:Person>

  <foo:Organization rdf:about="http://www.foo.com/ids/0739">
    <dc:title>ISOGEN</dc:title>
    <foo:parent-org rdf:resource="http://www.foo.com/ids/2957"/>
  </foo:Organization>

  <foo:Organization rdf:about="http://www.foo.com/ids/2957">
    <dc:title>DataChannel</dc:title>
  <foo:Organization>

It's a little verbose, but it does keep the data properly normalized
and uniquely identified.  The XMI for this might be a little less
readable, I'd think.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 12:18:51 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:31 2004
Subject: What do XML consultants actually do?
In-Reply-To: kragen@pobox.com's message of "Mon, 22 Nov 1999 23:12:42 -0500 (EST)"
References: <Pine.GSO.4.10.9911222238540.4442-100000@kirk.dnaco.net>
Message-ID: <m3yabpmmf8.fsf@localhost.localdomain>

kragen@pobox.com (Kragen Sitaker) writes:

> David Megginson writes

> > What companies hire consultants for is to help them understand how
> > to exchange and process information: 90% of the complexity comes
> > from the nature of the information they're trying to model and the
> > business environment in which they work, 9.9% of the complexity
> > comes from finding, learning, and integrating the software
> > components, and perhaps the remaining 0.1% has something to do
> > with the syntax of the markup layer (but probably not).
> 
> So in a $1 million project, perhaps $1,000 of the effort goes to things
> like implementing DTDs, 

Actually, many don't need DTDs specifically, but when they do, almost
all of the complexity of implementing DTDs belongs to the 90% (the
complexity of the information being modelled) -- sure, sometimes I
miss a closing quotation mark for mispell a parameter entity name, but
the parser brings me right to the error and I can fix it in a second
or two.  The time I spend figuring out how to arrange the information
in the DTD does not belong to the syntax, since I'd have the same
problem with XML Schema, RDF Schema, UML, DDML, or BNF.

> verifying that input is in the correct form, fixing bugs in
> outputting XML, etc.?  Sounds reasonable, if perhaps a little low.
> But maybe the projects you're working on are much bigger and harder
> than the ones I'm familiar with.  In fact, that seems quite likely.

Again, verifying that the input is correct is not specifically an XML
syntax problem -- you would still have to verify the input with SGML,
SML, s-expressions, or whatever.  The only complexity that belongs to
the syntax layer is the extra complexity that you have from XML and
not from the others.

As for output, there's not much to worry about if you're using a
library to output the XML and the library isn't buggy.  Again, you
have to make sure that the right information is in the right place,
but that's not an XML syntax problem.

> I suggest that the most important projects are the small ones.
> ArborText is undoubtedly tremendously significant, and no doubt the
> syntax of SGML contributes very little to its complexity.  But the
> significance of Arbortext is outweighed by the hundreds of little XML
> programs people have hacked up -- programs that would never have been
> attempted if understanding SGML were a prerequisite.

Not at first, I agree, but if XML didn't exist and there were 20 or 30
small SGML parsers in every language and a lot of excitement, they'd
probably be fine.  

After all, think of how many people program with sockets and how few
actually know how TCP/IP works at the low level; or, think of how many
people program with OpenGL or DirectX and how few could actually
explain the rendering pipeline.  

Simplicity gets you the libraries; the libraries get you the
applications.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abcoates at TheOffice.net  Tue Nov 23 12:44:36 1999
From: abcoates at TheOffice.net (Anthony B. Coates)
Date: Mon Jun  7 17:17:31 2004
Subject: If SAX == lex, then what == yacc?
References: <199911221306.AAA05146@mail.internetezy.com.au>
Message-ID: <199911231253.XAA19638@mail.internetezy.com.au>

** Reply to message from "James Tauber" <jtauber@jtauber.com> on Mon, 22 Nov
1999 09:20:43 -0500

Dear James,

	What you describe (included below) strikes me as using SAX events to build a
not-quite-DOM tree, which is exactly what I would expect FOP to do.  However, I
can envisage applications, operating on either large or streaming XML files,
where building a tree is not an appropriate solution.  Compilers (traditionally)
don't build a tree version of a source file before they start outputting the
object code to a file.  This is the kind of operation I am imagining.  I know I
myself would find it useful.  Mind you, I will be surprised if nobody has looked
into writing something like an XML version of 'yacc'.

	If someone published an XML Schema for C programs (don't laugh ...), what
would be the best way to write a compiler that reads this format but otherwise
runs like a typical C compiler?  Is there something that supercedes 'yacc' for
XML purposes?  I would be grateful for any suggestions from anyone.

	Cheers,
			Tony.

> FOP (and I suspect a lot of XML applications) takes SAX events and builds a
> tree structure out of objects that belong to a class depending on the
> element type or attribute. This tree building is handled through a largely
> generic builder and the mappings from element and attribute name to class
> name are provided to the builder at run-time. In the case of attributes (and
> perhaps eventually elements), the actual classes themselves are generated
> from XML schemas.
> 
> I don't know if it is the equivalent of "yacc" but it seems to be a fairly
> generic way of dealing with event streams that still allows
> application-specific tailoring.


** Anthony B. Coates    >> mailto:abcoates@TheOffice.net <<
** Software Engineer (Java).  This is a 100% Pure Java e-mail.
** AJUG National Secretary (see http://www.ajug.org.au/)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Tue Nov 23 12:50:59 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:31 2004
Subject: facts, conclusions, and exhortations re XML (long)
References: <199911210111.TAA00461@bruno.techno.com> <3839E823.2E2E6391@prescod.net>
Message-ID: <002d01bf35b0$33f602a0$51bdb3c7@WORKGROUP>


----- Original Message -----
From: Paul Prescod <paul@prescod.net>
To: <xml-dev@ic.ac.uk>
Sent: Monday, November 22, 1999 8:04 PM
Subject: Re: facts, conclusions, and exhortations re XML (long)


>
>  4. Hardly anybody uses IE5 client-side stylesheet for production work.
> To start with, no serious web publisher can afford to alienate the vast
> majority of users using non-IE5 client software.

I agreee with everything else here, but I believe the exact opposite is
true:  The vast majority of XML client seats supporting XSL use IE5, and Web
publishers use the IE5 "technology preview" flavor of XSL as a de-facto
standard.

I hope I'm wrong ... but if so, what *do* this vast majority of users use?


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



From micsik at sztaki.hu  Tue Nov 23 15:41:09 1999
From: micsik at sztaki.hu (Andras Micsik)
Date: Mon Jun  7 17:17:31 2004
Subject: Software to parse, browse and manipulate DTDs
Message-ID: <Pine.GSO.4.10.9911231621030.14988-100000@lutra.sztaki.hu>


I have been looking for a tool that is capable to read in an XML DTD, and
do some processing on that: create a new XML document and dynamically fill
it in according to the DTD, browse elements, attribute lists, etc.

Do you know such tool in Java?

Thanks in advance,
			Andras Micsik

-----------------------------------------------------------
  Andras Micsik              micsik@sztaki.hu
  MTA SZTAKI Hungary         http://www.sztaki.hu/~micsik



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



From martind at netfolder.com  Tue Nov 23 15:28:44 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:31 2004
Subject: What do Biztalk want to acheive?
Message-ID: <NBBBJPGDLPIHJGEHAKBAMEGAEHAA.martind@netfolder.com>

Hi,
No its not a flame against Microsoft :-) Its a reflection on what a biztalk
message is trying to achieve and what is missing in the actual XML world to
have what biztalk is trying to achieve.

Funny note: Mark, you know what, my Outlook spell checker wants also to
replace the biztalk word with bestial :-))) every time I see that, I laugh.
Microsoft embedded some humor in its outlook spell checker :-)))


1. Background:
--------------
Documents transferred from one place to an other can contains several
elements not part of the information model this document serialize (if the
document is a data model serialization as found in e-commerce applications).
a) the first meta information is the <?xml?> processing instruction
providing meta information about the document format and parsing
instructions. This element is an answer to the questions: "How can I parse
this document?", "How is this document encoded", etc... So, the element
contains info about the encoding, the version and so on and so forth.
b) the document type or DTD information. This element points or include the
meta information about the document structure. This is an answer to the
question: "What is the document's structure?". For more precision on the
structure and the data content type, a schema can be used instead.
c) the third element not part of the information model is the
<?xml-stylesheet?> element. This element is an answer to the question: "How
do I render this document?". it provides sufficient information to render
the document. the style sheet could be externally linked or embedded in the
document. What is interesting thought is to examine the document when the
style sheet is embedded. The example below shows a style sheet embedded in
an XML document.

<?xml version="1.0"?>
<?xml-stylesheet href="#style" type="text/xsl" media="screen"?>
<!DOCTYPE MyInvoice
.... the doc type content here but the document type
	do not include any references to the xsl name space,
	only defines the MyInvoice document type ...
>
<MyInvoice>
<xsl:stylesheet id="style"
                version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
....the style sheet content here...
</xsl:stylesheet>
.... the document content here.....
</MyInvoice>

2. interesting facts to note about the previous example:
-------------------------------------------------------
a) The document type do not mention anything about the style sheet.
Therefore the style sheet can be included in a document even if this
document type has no mention of the <xsl:stylesheet> element. According to
the XSLT recommendation, the above document is valid. Then, a validating
parser should only consider elements not part of the "xsl" namespace in its
validation process. <Question to the group> Is this the same for any other
elements part of a foreign namespace? <explanations> if we include elements
part of a different name space (i.e. a different name space than the defined
document type in the !doctype section). Then the validating parser should
not include these foreign name space elements in its validation process.
b) So, a validating parser can check for the document consistency even if
foreign name space elements are included in the document. For the moment,
without making a generalization on this, let's just consider that the "xsl"
name space can freely be included in the document without affecting its
consistency.

Thus, we are able to include foreign "xsl" name space elements in the
"MyInvoice" document without affecting its consistency. We still deal with
the "MyInvoice" document type and therefore with the "MyInvoice" document.

3. What biztalk is trying to achieve?
--------------------------------------
Biztalk is trying to provide an answer to the following questions:
a) from whom (or what) is this document coming from?
b) to whom (or what) is this document going to?
c) In which process is this document involved?
d) What is the transport used to move this document to its destination ?
etc...

we can say that all these information are meta information about the
document or the data model. It is about the data model it is not the data
model. Thus, biztalk is trying to provide meta information about the
document. It does so, by creating a new document type and by including your
document as a fragment into the document type. Is this the best solution? I
do not know. Is there any alternative ways to do it? Yes you bet.

4. Suggestion:
--------------
As we did for style sheets, why not do the same thing for meta information.
To recap: the original data model document is augmented or includes the
following elements, which are, from the data model point of view external
and are either meta information or processing information.
a) link to or includes the document type meta information
b) link to or includes the rendition processing information
c) inclusion of the document format meta information

Thus, why not add other meta information link or inclusion. For instance, to
link or include RDF statements about the document. This way we can achieve
what Biztalk is trying to achieve but in a more standard way.
This could be done with:
a) a processing instruction as for style sheets(ex: if linked <?xml-meta
href="mymeta.rdf" ?> or if included <?xml-meta href="#rdf"?> )
b) as a specialized element (ex: <rdf:RDF>)

Note about (b). If it is true that validation do not involve foreign name
spaces like it is the case for the "xsl" name space, then we can already
include in a document a <rdf:RDF> section without affecting its structure
and therefore without affecting its validation with a DTD or schema.

Therefore, if we can include a <rdf:RDF> element, then we can answer to the
questions biztalk is trying to answer.
Example:
<?xml version="1.0"?>
<?xml-stylesheet href="#style" type="text/xsl" media="screen"?>
<!DOCTYPE MyInvoice
.... the doc type content here
>
<MyInvoice>
<xsl:stylesheet id="style"
                version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
....the style sheet content here...
</xsl:stylesheet>
<rdf:RDF>
<biztalk:from>your humble servant</biztalk:from> <------  from whom (or
what) is this document coming from?
<biztalk:to>a potential buyer</biztalk:to> <------------  to whom (or what)
is this document going to?
<biztalk:procurement>billing</biztalk:procurement> <----  In which process
is this document involved?
.....more meta info about the document here ....
</rdf:RDF>
.... the document content here.....
</MyInvoice>

Or if the industry would agree on a common messaging system. We could then
propose a set of properties like the librarian people did with the Dublin
core.

Interesting things to note about the suggestion:
------------------------------------------------
a) the document is not transformed into a fragment and included in an other
document. we instead included meta information about the document. The
document kept its integrity.
b) A common task group could define a set of properties for documents used
for messaging.
c) we leverage the standards, we are not creating new ones or letting a
manufacturer set the rules.

Note to Tim [Berners-Lee]
------------------------
To create the semantic network, we need to be able to associate (or include)
meta information to the documents. On the web, document are transferred from
a server to a client with rendition instructions. Why not then also include
Meta information about this document so that the client gets the context for
this document, or meta information about this document. The key word here is
"context". In witch context this document is living in. Can we add some
meaning to this document existence?

But Tim, if I where rich enough I would be member of W3C and would propose
what I just mentioned in this document. But the only thing I can do is sing
"if I where a rich man...". I can be part of a IETF group because I can
afford it (its free) or be part of ISO (its also free) but not part of W3C
(its not free).

But what is important though, is not my W3C membership or my membership to a
golf club :-) It is that we start to discuss about the inclusion of meta
information in documents (as links or included). Make it clear that the
validation process for parsers do not concern foreign name space or standard
name spaces like "xsl" or "rdf" (the XSL name space is a good start to
illustrate this fact). Make it clear that something like biztalk is trying
to achieve is possible with the existing standards without affecting the
document integrity or structure. I do not say here to show that Microsoft is
wrong. I say here to show how something like biztalk is trying to acheive is
already part of the XML standards.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 23 15:56:55 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:31 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <199911231056253.SM01008@Unknown.>

I said:
>
> >>The fact is, I *despise* palmtops when it comes to documents 
> >>bigger than, say, your average shopping list.

Don said:
> 
> Palmtops will get slightly bigger display with much higher
> resolution and color in the future which will greatly enhance
> readability.  Note that most people have no problem reading
> paperback novels which are just slightly bigger than Palmtops.

I just happen to have both my palmtop and a paperback handy.  My palmtop (a Casio 
Pocket Viewer) is about 3" wide by 5" tall.  Of that, the display is about 2.5" square, not 
counting the part of the screen reserved for the menu icons (which are actually screened 
onto the plastic).  By comparison, the paperback is about 4" wide by 7" tall, and all of 
that is viewable area.  (In fact, I could even argue that the viewable area is really 8" by 
7", because you can see two pages at once.  This is a very important consideration to my 
"mindspace" argument; how much document can you see at once?)  In other words, that 
paperback has 56 square inches of visual space - the Casio has just over 6.  In no way, 
shape, or form does this qualify as "slightly" bigger.  That paperback is actually much 
closer to the size of a small monitor or a laptop screen than to a palmtop.

To put this into a more practical form, that paperback displays two columns of text at 36 
50-character lines each.  (Yes, I counted.  Random page, random full-length line, and 
this is a Young Adult novel to boot - which means larger type.)  Let's rearrange those 
numbers a little bit - say, to 72 x 25.  Look familiar?  It should; that's really close to a 
standard 80x25 DOS display, flipped up on one side...and that's only one of the pages; 
double it for the full view and you're at 80x45.  By comparison, my Casio displays 
25x16 at best (full-screen mode), and 20x12 is standard.  Rather a shocking comparison, 
wouldn't you say?  I daresay that no amount of "slightly larger display" and higher 
resolution will compensate for this huge discrepancy.

Now, if you want something which would catch my eye, steal a clue from about twenty 
years ago and rev it into overdrive.  See, back in the early 1980s, Nintendo came out 
with some handheld games that were built around about the same form factor as the 
modern palmtop.  (Yes, these were arguably the grandparents of the Gameboy.)  One 
particularly memorable experiment was a clamshell design - you opened the game on a 
hinge, revealing two screens with the controls arranged around the bottom one.  Now, 
imagine a palmtop with this basic layout.  Open it up like a micro-laptop, make the "top" 
screen display-only (less expensive!) and save the touch-sensitive tech for the bottom 
screen.  In data browsing mode, you could use both screens together to make a book-
style interface, or maybe even display two different documents - one on each screen.  Is 
anybody following me on this?
 
> With better contrast and something like ClearType, you will
> be amazed at the differences.  There is a lot of room for
> improvement in the UI design as well.  What we have now
> simply sucks less than before.  Handwriting recognition
> will also improve drastically soon.  Some of the prototypes
> I have seen is amazing.  The writing surface will also improve
> to feel more like paper rather than feeling like skating over
> thin ice.

See, all that just misses my point entirely.  I don't care what the writing surface feels like.  
I don't care about handwriting recognition - in fact, my Casio doesn't include it at all.  
My concern is that I can't write a coherent article when I can't even glance up to see 
what I wrote last paragraph - and that's purely a function of the limited visual area.  The 
only thing that will help that is to make the screen bigger - and that clamshell trick is 
probably about the only practical way to do that to any large degree.  (Not to mention 
that it automatically provides screen protection and covers the buttons!)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 23 16:12:10 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:31 2004
Subject: Microsoft, XML, and the real specs
Message-ID: <199911231112482.SM01008@Unknown.>

> ** Original Sender: Paul Prescod <paul@prescod.net>
>
> Microsoft labels these features "technology previews." They know that
> some stupid people will build real systems on them but they say, quite
> rightly, that those systems will break with new versions of the tools
> and those people "get what they deserve." If it were Netscape issuing
> these technology previews we would laud them for testing out new ideas
> and providing feedback to the standards process (which Microsoft DOES
> DO).

Excuse me - ever hear of a little project called "Mozilla"?  I mean, if you want to talk 
tech previews....
 
> Let's give credit where it is due. The practice of shipping "technology
> previews" has benefits and costs but Microsoft's history indicates that
> they move to the real specifications when they become available.

Since when?  I'm running IE 5.01 right now - and it still doesn't handle HTML 4 or parts 
of CSS1 properly.  CSS2?  In your dreams.  Granted, it's better than the Netscape 4.7 
support - but Mozilla blows it away.  As far as I can tell, Microsoft has only "moved to 
the real specifications" when it can make some hay by doing so - and even then, the 
support is incomplete.  (I refer you to the long-ago announcement of CSS1 support in 
IE3 - only on Win95, and just enough support to make a couple of flashy examples.  
XML and IE5 now look much the same from where I sit - a lot of noise, but not much 
substance.  In fact, when considering my HTML/XML redirection routine, the only 
conclusion I could reach in good conscience was to turn IE5 away from the XML pages.  
It works okay, but it's not compliant - and I'm not going to start my XML designs by 
coding in legacy hacks.  I'd much rather wait until a compliant browser hits the scene 
than rush in to support a noncompliant one just so I can say I've done it.)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 16:12:29 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:31 2004
Subject: RDF, again
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain>
Message-ID: <383A900C.F3BBA15C@prescod.net>

> > Without the minimization hacks, the syntax is verbose and hard to
> > read.
> 
> That's inevitable for any kind of object exchange, though -- it's the
> nature of the normalized object-oriented information.
> 
> Here's some mostly non-minimized RDF (using only the rdf:type as class
> name):

The thing I find confusing about the RDF syntax is that the element type
name can be either an RDF type name or an RDF property. XML makes no
distinction and that's why I think that it is difficult to use for
object oriented interchange. Your example doesn't run into that problem
really because it only goes one level deep. But what does the RDF for
this CSS-style object representation look like:

person{
	name: person-name{ first: "Paul"; last: "Prescod"};
	address: snail-mail-address{
		street: street-address{
			number: 5936; 
			street: "Lovers Lane"
		city: city( #!Dallas );
		state: state( #!Texas )};
	siblings: #sibling1 #sibling2 #sibling3}

(curly braces for structures, parentheses for primitive types,
concatenation for lists, semicolons for property separators)

<ramble>
Note also that common XML usage puts datatypes in the schema or
elsewhere. To recognize an integer as such you need the schema or some
other external knowledge. Some DTDs have <int> elements but that's so
ugly that it hasn't really "caught on." The XML world is very
inconsistent in its thought about the appropriateness of dependence on
the schema. I think that that dependence is slowly creeping back into
vogue.

Speaking on behalf of the devil, I'd say that in one week we could
define (or just find) an S-expression-like language with none of these
weaknesses and in less time we could write a parser for it. It could
have "XML element" as a primary data type for embedded XML and could
also be embedded IN XML.

I am enough of a language aficionado to feel that there is virtue in
having languages that are immediately interpretable. Languages where the
semantics "fall out" visually. But I know you are a Perl programmer so I
won't ask you to agree.

The fashionable thing is to say that these are problems that can be
hidden "behind a good GUI" but here we are, (more than?) twenty years
into the Age of Emacs and the best IDEs are still designed to help us
type text faster. Unless we are going to standardize graphical
representations of RDF graphs, and send those representations through
email, and embed RDF renderers and editors in every device, people will
still look at the text.
</ramble>

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
It's such a 
Bore
Being always
Poor
LANGSTON HUGHES
http://www.northshore.net/homepages/hope/engHughes.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Tue Nov 23 16:30:34 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:31 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
References: <199911231056253.SM01008@Unknown.>
Message-ID: <003a01bf35d0$0d304480$46d88dce@sagus.com>


----- Original Message -----
From: <rev-bob@gotc.com>
To: Don Park <donpark@docuverse.com>; <xml-dev@ic.ac.uk>
Sent: Tuesday, November 23, 1999 11:00 AM
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)


>
> See, all that just misses my point entirely.  I don't care what the
writing surface feels like.
> I don't care about handwriting recognition - in fact, my Casio doesn't
include it at all.
> My concern is that I can't write a coherent article when I can't even
glance up to see
> what I wrote last paragraph - and that's purely a function of the limited
visual area.  The
> only thing that will help that is to make the screen bigger - and that
clamshell trick is
> probably about the only practical way to do that to any large degree.
(Not to mention
> that it automatically provides screen protection and covers the buttons!)

I think that misses the point of ultralight clients!  I wouldn't expect to
write a novel, or code, on my cellphone, and I don't want to lug around even
my Sony Vaio (about 2 lb ultraslim notebook) to make phone calls.  In
between those extremes there's a lot I *would* like to do on my cellphone
that (being in the US) I can't do yet, like scan my email for anything
important, check my travel arrangements on Web sites, maybe read some news
headlines or see how badly my lastest XML-DEV posting is being flamed ;~)

I would *rather* do these things on a notebook PC form factor, but not at
the cost of lugging it around, spending 2-3 minutes to start it up, having
to recharge it every couple of hours, etc.  The phone is better in these
respects.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 16:35:08 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:31 2004
Subject: facts, conclusions, and exhortations re XML (long)
References: <199911210111.TAA00461@bruno.techno.com> <3839E823.2E2E6391@prescod.net> <002d01bf35b0$33f602a0$51bdb3c7@WORKGROUP>
Message-ID: <383ABDD3.3DB48DCF@prescod.net>

Michael Champion wrote:
> 
> I agreee with everything else here, but I believe the exact opposite is
> true:  The vast majority of XML client seats supporting XSL use IE5, and Web
> publishers use the IE5 "technology preview" flavor of XSL as a de-facto
> standard.
>
> I hope I'm wrong ... but if so, what *do* this vast majority of users use?

Server-side XSL or none at all. I don't think I've ever browsed a web
page that used client-side XSL *EXCEPT* as an explicitly highlighted
demo (read "experiment").

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon

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



From nisse at lysator.liu.se  Tue Nov 23 16:44:16 1999
From: nisse at lysator.liu.se (Niels Möller)
Date: Mon Jun  7 17:17:31 2004
Subject: RDF, again
In-Reply-To: Paul Prescod's message of "Tue, 23 Nov 1999 14:01:00 +0100"
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net>
Message-ID: <nnso1x17lf.fsf@sanna.lysator.liu.se>

Paul Prescod <paul@prescod.net> writes:

> Speaking on behalf of the devil, I'd say that in one week we could
> define (or just find) an S-expression-like language with none of these
> weaknesses and in less time we could write a parser for it. It could
> have "XML element" as a primary data type for embedded XML and could
> also be embedded IN XML.

People on this list keep mentioning S-expressions. I'm not sure if you
are talking about lispish syntax in general, or some more precisely
defined language? In the latter case, are you speaking about the
language defined at http://theory.lcs.mit.edu/~rivest/sexp.html? It is
about one order of magnitude easier to parse than XML. The only
application of it that I know of is SPKI (Simple Public Key
Infrastructure).

/Niels

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 16:43:36 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:32 2004
Subject: Microsoft, XML, and the real specs
References: <199911231112482.SM01008@Unknown.>
Message-ID: <383ABE2F.6A1FD8D9@prescod.net>

rev-bob@gotc.com wrote:
> 
> Excuse me - ever hear of a little project called "Mozilla"?  I mean, if you want to talk
> tech previews....

I'm not clear on what standards Mozilla "previews." It has some of its
own stuff like XUL and it has good support for existing stuff like XML
and CSS and it is moving to support some new stuff like XSL...but I
don't see it doing anything similar to what Microsoft calls a technology
preview.

Anyhow, it's irrelevant. If you are right that Mozilla has technology
previews then I am right that nobody is raising a huge fuss about it and
claiming that they are trying to take over the world.

> Since when?  I'm running IE 5.01 right now - and it still doesn't handle HTML 4 or parts
> of CSS1 properly. CSS2?  In your dreams.  Granted, it's better than the Netscape 4.7
> support - but Mozilla blows it away.  

Okay, so Microsoft's year-old browser isn't as good as Netscape's not
yet released one. Hardly a fair comparison. Rendering structured text is
hard. Verifying conformance is hard. Microsoft has, thus far, screwed it
up, as has Netscape. I see this not as evidence of a plot to take over
the world but rather as the sort of thing that happens in the Real World
with Real Programmers. As long as Microsoft keeps moving TOWARDS
standards conformance, I will keep applauding them when they do so.

> It works okay, but it's not compliant - and I'm not going to start my XML designs by
> coding in legacy hacks.  I'd much rather wait until a compliant browser hits the scene
> than rush in to support a noncompliant one just so I can say I've done it.)

That's what I encouraged you to do in my last message.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon

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



From Colas.Nahaboo at sophia.inria.fr  Tue Nov 23 16:54:44 1999
From: Colas.Nahaboo at sophia.inria.fr (Colas Nahaboo)
Date: Mon Jun  7 17:17:32 2004
Subject: If SAX == lex, then what == yacc? 
In-Reply-To: Your message of "Tue, 23 Nov 1999 00:57:19 +0700."
             <199911221306.AAA05146@mail.internetezy.com.au> 
Message-ID: <199911231614.RAA09274@aye.inria.fr>



"Anthony B. Coates" writes:

> A thought that struck me (and probably struck many of you before me) is that
> the event stream from a SAX parser is much like the token stream from a lexical
> analyser, like 'lex'.  This made me wonder what the equivalent to 'yacc' would
> be in this picture;

It would be an API that would build a tree from SAX events. DOM is such an
API, which has the advantage of being a W3C reccomendation. However, using a
general DOM implementation as a layer on top of SAX can only be used for
quick-n-dirty jobs, as you will force your application to go through too
abstract a layer to be efficient.  I suggest you use our DOM-light DOM subset 

	http://www.inria.fr/koala/domlight/

which is a good step in the right direction, but you will find that if your
application is not toy-sized, you will end up using DOM to query the parse
tree and build the internal structure necessary in your application, thus
duplicating the work.

Note that I dont know of an exact equivalent of yacc for XML... something that 
would implement listeners for building nodes, providing you with some kind of
"buffer" to allow you to build your tree "top-down" instead of "bottom-up"
from SAX lexical events... Do somebody know if such a tool exists?

--
Colas Nahaboo, Koala/Dyade/Bull @ INRIA Sophia, http://www.inria.fr/koala/colas


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 23 16:57:17 1999
From: schen at falconwing.com (Sean Chen)
Date: Mon Jun  7 17:17:32 2004
Subject: If SAX == lex, then what == yacc?
In-Reply-To: <199911231253.XAA19638@mail.internetezy.com.au>
Message-ID: <Pine.LNX.3.96.991123113600.7948A-100000@www.falconwing.com>

Hi Anthony, everyone,

On Wed, 24 Nov 1999, Anthony B. Coates wrote:

> ** Reply to message from "James Tauber" <jtauber@jtauber.com> on Mon, 22 Nov
> 1999 09:20:43 -0500
> 
> 	What you describe (included below) strikes me as using SAX
> events to build a not-quite-DOM tree, which is exactly what I would
> expect FOP to do.  However, I can envisage applications, operating on
> either large or streaming XML files, where building a tree is not an
> appropriate solution.  Compilers (traditionally)  don't build a tree
> version of a source file before they start outputting the object code to
> a file. 

Er... minor correction here.  Compilers *do* traditionally build a tree
version of a source file, it's called the AST, Abstract Syntax Tree. 

Back on topic, what you're looking for might be done by MDSAX, or Coins
(whatever it is called nowadays). 

. . . 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 17:11:02 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:32 2004
Subject: SGML, XML and SML
Message-ID: <3.0.32.19991123090722.0146e7e0@pop.intergate.ca>

At 01:10 AM 11/23/99 -0800, Don Park wrote:
>As for me, CDATA is out because it is a convenience feature
>and a hack to boot.

A hack and a convenience feature, true, but damn convenient.  Particularly
when you've just invented a new xml-based language and are writing the
documentation and want to paste in examples.  Which is admittedly not a
high-volume use-case, but one that nearly every early adopter has to deal
with.

Having said all that, it is indeed a hack. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From RDaniel at DATAFUSION.net  Tue Nov 23 18:14:11 1999
From: RDaniel at DATAFUSION.net (Ron Daniel)
Date: Mon Jun  7 17:17:32 2004
Subject: If SAX == lex, then what == yacc? 
Message-ID: <0D611E39F997D0119F9100A0C931315C52FB1C@datafusionnt1>

> "Anthony B. Coates" writes:
> 
> > A thought that struck me (and probably struck many of you before me) is
> that
> > the event stream from a SAX parser is much like the token stream from a
> lexical
> > analyser, like 'lex'.  This made me wonder what the equivalent to 'yacc'
> would
> > be in this picture;
> 
[Ron Daniel]  A tool that took a DTD and generated a SAX
DocumentHandler for parsing instances that are to conform
to the DTD. (This much is not too hard to do for basic element
and attribute declarations.)

The next step would be to add the equivalent
of yacc actions (e.g.  $$ = $1 + $2  if my memory of yacc
serves) to the DTD so that in addition to validating the
instance you can store it into a desired structure, perform
arbitrary calculations, etc.

Regards,
Ron


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



From jmcdonou at library.berkeley.edu  Tue Nov 23 18:29:08 1999
From: jmcdonou at library.berkeley.edu (Jerome McDonough)
Date: Mon Jun  7 17:17:32 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <199911231056253.SM01008@Unknown.>
Message-ID: <199911231828.NAA01826@westnet.com>

At 11:00 AM 11/23/99 -0500, rev-bob@gotc.com wrote:
>Now, if you want something which would catch my eye, steal a clue from about
twenty 
>years ago and rev it into overdrive.  See, back in the early 1980s, Nintendo
came out 
>with some handheld games that were built around about the same form factor as
the 
>modern palmtop.  (Yes, these were arguably the grandparents of the Gameboy.) 
One 
>particularly memorable experiment was a clamshell design - you opened the
game
on a 
>hinge, revealing two screens with the controls arranged around the bottom
one.  Now, 
>imagine a palmtop with this basic layout.  Open it up like a micro-laptop,
make the "top" 
>screen display-only (less expensive!) and save the touch-sensitive tech for
the bottom 
>screen.  In data browsing mode, you could use both screens together to make a
book-
>style interface, or maybe even display two different documents - one on each
screen.  Is 
>anybody following me on this?


Actually, they're way ahead of you on this.  Well, not *way* ahead, because
it's a little
larger than you might like, but have a look at http://www.everybook.net/
and see
if
it isn't close to what you have in mind.  Certainly they have grasped your
desire for
a two screen, clamshellf reading device.


Jerome McDonough -- jmcdonou@library.Berkeley.EDU  |  (......)
Library Systems Office, 386 Doe, U.C. Berkeley     |  \ *  * /
Berkeley, CA 94720-6000    (510) 642-5168          |  \  <>  /
"Well, it looks easy enough...."                   |   \ -- /  SGNORMPF!!!
         -- From the Famous Last Words file        |    ||||

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 19:16:54 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:32 2004
Subject: Still news
Message-ID: <3.0.32.19991123111757.0141c280@pop.intergate.ca>

XML is the cover story on PC week; coverage effusive even by the standards
we've started getting used to.  Check out http://www.zdnet.com/pcweek/

 -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From paulo at samsara.com  Tue Nov 23 19:14:04 1999
From: paulo at samsara.com (Paul O'Rorke)
Date: Mon Jun  7 17:17:32 2004
Subject: facts, conclusions, and exhortations re XML (long)
References: <199911210111.TAA00461@bruno.techno.com> <3839E823.2E2E6391@prescod.net> <002d01bf35b0$33f602a0$51bdb3c7@WORKGROUP>
Message-ID: <383AE7B0.55BE4347@samsara.com>

I think you are wrong.  At least in the case of business to consumer e-commerce sites.  Those
sites, when they use XML, they are using xml on the server side and rendering it as HTML that
gets sent down the wire to clients.
---Paul O

Michael Champion wrote:

> ----- Original Message -----
> From: Paul Prescod <paul@prescod.net>
> To: <xml-dev@ic.ac.uk>
> Sent: Monday, November 22, 1999 8:04 PM
> Subject: Re: facts, conclusions, and exhortations re XML (long)
>
> >
> >  4. Hardly anybody uses IE5 client-side stylesheet for production work.
> > To start with, no serious web publisher can afford to alienate the vast
> > majority of users using non-IE5 client software.
>
> I agreee with everything else here, but I believe the exact opposite is
> true:  The vast majority of XML client seats supporting XSL use IE5, and Web
> publishers use the IE5 "technology preview" flavor of XSL as a de-facto
> standard.
>
> I hope I'm wrong ... but if so, what *do* this vast majority of users use?
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Tue Nov 23 19:40:57 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:32 2004
Subject: Still news
References: <3.0.32.19991123111757.0141c280@pop.intergate.ca>
Message-ID: <008601bf35ea$a5c60260$46d88dce@sagus.com>


----- Original Message -----
From: Tim Bray <tbray@textuality.com>
To: <xml-dev@ic.ac.uk>
Sent: Tuesday, November 23, 1999 2:18 PM
Subject: Still news


> XML is the cover story on PC week; coverage effusive even by the standards
> we've started getting used to.  Check out http://www.zdnet.com/pcweek/

And InfoWorld as well -- although the coverage is not at all effusive (The
overall headline is "Tag Trouble" and the title of the lead article is "XML
stumbling blocks").  The actual articles are fairly positive, however.  I
especially like the interview with Simon Phipps.
http://www.infoworld.com/cgi-bin/displayStory.pl?interviews/991122phipps.htm

When asked the usual question about the e-commerce standards and the danger
that MS or someone will impose proprietary formats and protocols, he
replied:

"[Y]have to first of all understand that the most important XML standard is
actually XSL [Extensible Style Language], not XML. What's going to happen
with XML is that people are going to represent their business data
structures as hierarchical data structures marked up with XML. Let's assume
that you and I are in the same business. We have a different business model
because we are in different businesses. Therefore, it's likely that we will
have different hierarchical data structures for the way we represent data.
So, just for you and me -- in the same business -- to express ourselves, we
will probably need to have slightly different vocabularies. Consequently,
the lifeblood of all business to business in XML is going to be
transformation. And if the lifeblood of XML is going to be transformation,
it doesn't really matter if vendors produce slightly different XML standards
because at least the data's all marked up."


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 19:59:34 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:32 2004
Subject: Still news
References: <3.0.32.19991123111757.0141c280@pop.intergate.ca>
Message-ID: <01c101bf35ed$c1c815e0$1918ccce@murphy>

"However, XML isn't a good choice for internal systems deployment.
Technologies such as Common Object Request Broker Architecture and
Distributed Component Object Model are far superior at wire-level
communication, security and data typing."

Grrrrrrrrrrrr.

Dave


----- Original Message -----
From: Tim Bray <tbray@textuality.com>
To: <xml-dev@ic.ac.uk>
Sent: Tuesday, November 23, 1999 11:18 AM
Subject: Still news


> XML is the cover story on PC week; coverage effusive even by the standards
> we've started getting used to.  Check out http://www.zdnet.com/pcweek/
>
>  -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 20:44:01 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:17:32 2004
Subject: W3C XML Linking working group publishes XInclude
Message-ID: <19991123154356.C8009@w3.org>

  One more piece to look at for those interested in the external
entities debate:

  XML Inclusion Proposal (XInclude)
  W3C Note 23 November 1999
  http://www.w3.org/TR/1999/NOTE-xinclude-19991123.html

 Note that:
  - This document is for discussion only, this is not currently a 
    "work in progress" (but this may change)
  - Public feedback is welcome (use www-xml-linking-comments@w3.org)

-----------------------
Abstract 

The purpose of this document is to set forth a minimal set of requirements
and introduce a processing model and syntax for a general purpose
inclusion facility. Inclusion is accomplished by merging a number of
XML Infosets into a single composite Infoset. Specification of the XML
documents (infosets) to be merged and control over the merging process
uses an XML-friendly syntax (elements, attributes, URI-References).
The general purpose inclusion mechanism is usable in well-formed but
not necessarily valid XML documents.

Status of this document

The XML Linking Working Group has decided to publish the XInclude
proposal as a W3C Note from the XML Linking Working Group. This is the
result of the evolution of the show="parsed" behaviour found in early
XLink Working Drafts. It was decided that this functionality would
be better handled in the core XML specification. Hence, at this time,
this document is for discussion purposes only. This Note may be updated,
replaced or rendered obsolete by other W3C documents at any time. It is
inappropriate to use W3C Notes as reference material or to cite them as
other than "work in progress". This document is for discussion only and
does not imply endorsement by the W3C membership.

This document has been produced as part of the W3C XML Activity by the
XML Linking Working Group. The XML Linking WG charter currently expires
in March 2000, but can be extended, if necessary.

Please send detailed comments on this document to the archived
mailing-list www-xml-linking-comments@w3.org.
-----------------------

Daniel XML Linking WG staff contact

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Tue Nov 23 22:00:46 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:32 2004
Subject: Still news
References: <3.0.32.19991123111757.0141c280@pop.intergate.ca> <01c101bf35ed$c1c815e0$1918ccce@murphy>
Message-ID: <009901bf35fe$73aac540$0b00a8c0@grissom>

Dave Winer said
>
> Grrrrrrrrrrrr.

Follow the link to the article by Peter Coffee:

"XML frees IT administrators from making an otherwise awkward choice between
CORBA and DCOM."

http://www.zdnet.com/pcweek/stories/jumps/0,4270,2396835,00.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From niko at cmsplatform.com  Tue Nov 23 22:22:58 1999
From: niko at cmsplatform.com (Nik O)
Date: Mon Jun  7 17:17:32 2004
Subject: SGML, XML and SML
Message-ID: <01da01bf3601$3d40fe40$1a5e360a@tetondata.com>

Kragen Sitaker wrote:
>
>I suspect CDATA sections are hard to live
>without if you're writing XML documents about
>HTML or XML, though.

I disagree.  Since a CDATA section cannot contain the "]]>" literal string,
the HTML/XML source being included in such a section must still be filtered
prior to inclusion in the XML document.  If you've conceded that a filter
must be applied, why not just filter for "<" and "&" instead (a generically
useful filter, BTW)?

Thus, the filtered XML might look like:
  <html_source>&lt;A HREF="www.w3.org"&gt;</html_source>

..whilst an alternate version is:
  <html_source><![CDATA[<A HREF="www.w3.org">]]></html_source>

I don't really see that using the equivalent CDATA section is all that much
easier to read or construct in the raw form, and once displayed in a browser
it's all good.

I am also in agreement with those who wish that CDATA had never made it into
XML, and believe that this would be a key simplification in SML, since
general XML parsing rules are overturned within CDATA sections.

Regards,
 Nik O, Teton Data Systems / Teton NewMedia, Jackson, Wyo.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 22:32:02 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:17:32 2004
Subject: Using namespace prefix in attribute values
Message-ID: <33D189919E89D311814C00805F1991F7F4A8E0@RED-MSG-08>

1.	The namespaces specification neither recommends nor disallows the
use of qnames in attribute values.  (What you put in your attributes is your
business.)

2.	The InfoSet Working group is responsible for recommending what
conforming parsers must expose to applications.  David Megginson is the
chairman, and he can likely give you current status.

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



From jamesr at steptwo.com.au  Tue Nov 23 22:52:25 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:17:32 2004
Subject: If SAX == lex, then what == yacc? 
In-Reply-To: <199911231614.RAA09274@aye.inria.fr>
References: <Your message of "Tue, 23 Nov 1999 00:57:19 +0700." <199911221306.AAA05146@mail.internetezy.com.au>
Message-ID: <4.2.0.58.19991124094600.00c9d750@203.41.126.17>


>
>"Anthony B. Coates" writes:
>
> > A thought that struck me (and probably struck many of you before me) is 
> that
> > the event stream from a SAX parser is much like the token stream from a 
> lexical
> > analyser, like 'lex'.  This made me wonder what the equivalent to 
> 'yacc' would
> > be in this picture;

I guess the closest thing I've seen is
Omnimark:

It's stream-based, event-driven, and maintains
a stack of open elements for you. It doesn't
build a whole in-memory representation of the
document either, unlike DOM.

Obviously I'm not saying it's identical
in concept, but in practice, it works well.

J

-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
Illumination: an out-of-the-box Intranet solution

http://www.steptwo.com.au/
jamesr@steptwo.com.au

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 23:46:30 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:32 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <199911231056253.SM01008@Unknown.>
Message-ID: <000b01bf360d$497d81e0$099918d1@docuverse1>

>See, all that just misses my point entirely.  I don't care 
>what the writing surface feels like.  
>I don't care about handwriting recognition - in fact, my Casio 
>doesn't include it at all.  
>My concern is that I can't write a coherent article when I 
>can't even glance up to see 
>what I wrote last paragraph - and that's purely a function of 
>the limited visual area.  The 
>only thing that will help that is to make the screen bigger - 
>and that clamshell trick is 
>probably about the only practical way to do that to any large 
>degree.  (Not to mention 
>that it automatically provides screen protection and covers 
>the buttons!)

Rev,

This is a misuse of Palmtops.  They are designed for writing
small notes and not for writing complete articles.  Some
people are using it to even write programs but that is
misuse as well. 

Again, I reiterate my position: slightly larger screen size
+ higher screen resolution + ClearType will increase readability
tremendously.  I guarantee that people will get a shock come
next X-mas.

BTW, I think we are off-topic for this list.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 23 23:46:30 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:32 2004
Subject: SGML, XML and SML
In-Reply-To: <Pine.SOL.4.05.9911231134140.2801-100000@granby>
Message-ID: <000901bf360d$46f80f80$099918d1@docuverse1>

>Don, do you think SML would be a good medium for then sending chunks of
>SVG  - have to keep the attributes, though. This way 'web browsers, etc
>can send/receive SML or XML fragments to update the display - obviously
>actual pixel resolution is important now, but for how much longer?

Yes.  Pixel resolution will be more important in the future.  Next X-mas.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 00:18:23 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:32 2004
Subject: RDF, again
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E909B@sohos002.ied-support.net>

Paul Prescod wrote:
> The thing I find confusing about the RDF syntax is that the 
> element type
> name can be either an RDF type name or an RDF property. XML makes no
> distinction and that's why I think that it is difficult to use for
> object oriented interchange.

I got the impression from the spec that this is intentional, so that a
straightforward XML document - that might not contain *any* RDF - can
still be interpreted as a set of RDF statements. In other words,
different XML layouts (elements for attributes, e.g.) of the same data
would result in the same RDF statements.

The XML would still need to be well thought out though. For example:

	<person name="Paul">
		<food>trifle</food>
	</person>

might mean trifle is your favourite food, the main food you're allergic
to, or your pudding preference for the office Xmas party. All of these
are acceptable in XML, but the RDF interpretation of this may well be
incorrect - or at least not as rich in meaning as we would like:

	Person has a name "Paul" and a food "trifle"

So, to make the first statement - trifle is Paul's favourite food - we
could use the following RDF:

<rdf:RDF>
	<rdf:Description ID="1">
		<rdf:Type rdf:resource="person" />
		<x:name>Paul</x:name>
	</rdf:Description>

	<rdf:Description ID="2">
		<rdf:Type rdf:resource="food" />
		<x:name>trifle</x:name>
	</rdf:Description>

	<rdf:Description about="#1">
		<x:favourite rdf:resource="#2" />
	</rdf:Description>
</rdf:RDF>

Using the abbreviated forms allowed to us, this is the same 'RDF':

	<x:person x:name="Paul">
		<x:favourite>
			<x:food>trifle</food>
		</x:favourite>
	</x:person>

or:

	<x:person>
		<x:name>Paul</x:name>
		<x:favourite>
			<x:food>trifle</x:food>
		</x:favourite>
	</x:person>

or:

	<x:person>
		<x:name>Paul</x:name>
		<x:favourite x:food="trifle" />
	</x:person>

So - to turn this round - any of the previous three XML documents can be
interpreted as the same set of RDF statements - a person with the name
"Paul" has a favourite food, and that food is called trifle - even
without any explicit RDF present.

As to whether it is any good for object interchange, I think it is. Of
course, if the relationships between elements contained within other
elements can be inferred then straight XML is fine. But as soon as you
need something more complex then RDF is very good (not to mention when
the objects being referred to are outside of the XML document you're,
and so you can't use ID/IDREF.)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 00:19:34 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:33 2004
Subject: What is a document?
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E909C@sohos002.ied-support.net>

Don Park wrote:
> We clearly have a need to delve deeper into XML fragments related
> issues and I believe this is one of them.
> 
> In my view, sometimes it makes sense for a particular XML fragment
> to specify constraints on its containers.  By its nature, a fragment
> is likely to be missing some information (parameters if you will) that
> must be provided by the context.  We currently have no mechanism to do
> this but we will need it eventually.

Not true - XML Fragment Interchange suggests a simple way to do all that
you say. I know that current thinking is that there's 'too many specs to
read', but this one's a teeny one.

Regards,

Mark


> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From begeddov at jfinity.com  Wed Nov 24 00:19:38 1999
From: begeddov at jfinity.com (Gabe Beged-Dov)
Date: Mon Jun  7 17:17:33 2004
Subject: RDF, again
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net>
Message-ID: <383B1E86.55020EC4@jfinity.com>


Paul Prescod wrote:

> The thing I find confusing about the RDF syntax is that the element type
> name can be either an RDF type name or an RDF property. XML makes no
> distinction and that's why I think that it is difficult to use for
> object oriented interchange. Your example doesn't run into that problem
> really because it only goes one level deep. But what does the RDF for
> this CSS-style object representation look like:

RDF/XML 1.0 uses a striped syntax of alternating Type/Property elements (you will see this
referred to as Type/Accessor in XML schema related discussions). This is perfect for object
oriented interchange and is fine once you keep track of nesting level by  twos
(type/accessor).

If you use the shorthand to specify the type as the element name rather than as the rdf:type
property  (this is how the Mozilla Directory dump does it) you save some typing and get a
more natural syntactic representation. If you also use  Java style naming conventions for
types vs. property names you can get even more  intuitive.

I've attached a slightly modified version of your CSS example in RDF. I changed the #!
references (what does #! mean?) to regular intra-document references and did something
similar to the siblings list so that everything would resolve by adding some dummy instances
at the end.

Cordially from Corvallis,

Gabe Beged-Dov
http://www.jfinity.com/gabe

-------------- next part --------------
<?xml version="1.0"?>
<rdf:RDF xmlns="http://www.rdfSchemas.org/person.rdf#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <Person rdf:ID="Paul1"> 
	<name> 
	    <Person-name> 
		<first>Paul</first> 
		<last>Prescod</last> 
	    </Person-name> 
	</name> 
	<address> 
	    <Snail-mail-address> 
		<street> 
		    <Street-address> 
			<number>5936</number> 
			<street>Lovers Lane</street> 
		    </Street-address> 
		</street> 
		<city> 
		    <City rdf:about="#Dallas" /> 
		</city> 
		<state> 
		    <State rdf:about="#Texas" /> 
		</state>
	    </Snail-mail-address> 
	</address> 
	<siblings> 
	    <rdf:Seq> 
		<rdf:li rdf:resource="#Paul3" /> 
		<rdf:li rdf:resource="#Paul2" /> 
		<rdf:li rdf:resource="#Paul4" /> 
	    </rdf:Seq> 
	</siblings> 
    </Person> 
    <Person rdf:ID="Paul2"></Person>
    <Person rdf:ID="Paul3"></Person>
    <Person rdf:ID="Paul4"></Person>
    <City rdf:ID="Dallas"></City>
    <State rdf:ID="Texas"></State>
    
</rdf:RDF>

From clovett at microsoft.com  Wed Nov 24 00:27:34 1999
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:17:33 2004
Subject: msxsl error
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C155E6395@RED-MSG-56>

A search on msdn will reveal that this error code means E_INVALIDARG.
msxsl was an old technology preview we replaced with MSXML.DLL in IE5.

See http://msdn.microsoft.com/xml for the latest information.

-----Original Message-----
From: Wo Chang, x3439 [mailto:wchang@nist.gov]
Sent: Sunday, November 21, 1999 1:29 PM
To: xml-dev@ic.ac.uk
Subject: msxsl error


Hi,

I once used the msxsl to generate html pages from
an xml input document via xsl style sheet, but now
when I try to run same program, it gives me the
following error message:

   Error parsing document 'abc.xml'
   Exception: hr= 0x80070057
   
The only different between before and now is I'm
running Win98 (with IE5) now and before was Win95 
(with IE4).

Can anyone help me to identify the cause of the
problem?  Was it due to the software expiration?
Or, do I need a newer version of msxsl for Win98/NT?
If I do, where can I get a newer version?  I kind 
of search the www.microsoft.com/xml but couldn't
find them.

Any helps would be greatly appreciated.

--Wo Chang


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 01:54:13 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:33 2004
Subject: If SAX == lex, then what == yacc? 
References: <0D611E39F997D0119F9100A0C931315C52FB1C@datafusionnt1>
Message-ID: <015801bf361e$cf58df10$eb020a0a@bowstreet.com>

> [Ron Daniel]  A tool that took a DTD and generated a SAX
> DocumentHandler for parsing instances that are to conform
> to the DTD. (This much is not too hard to do for basic element
> and attribute declarations.)
>
> The next step would be to add the equivalent
> of yacc actions (e.g.  $$ = $1 + $2  if my memory of yacc
> serves) to the DTD so that in addition to validating the
> instance you can store it into a desired structure, perform
> arbitrary calculations, etc.

Right. This is pretty much what I've started doing with FOP. I have a
schema-like document with additional calculations in it.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Wed Nov 24 04:29:13 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:33 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <199911232329888.SM01008@Unknown.>

> ** Original Sender: "Don Park" <donpark@docuverse.com>
>
> >See, all that just misses my point entirely.  I don't care what the writing surface feels
> >like.  I don't care about handwriting recognition - in fact, my Casio doesn't include it
> >at all.  My concern is that I can't write a coherent article when I can't even glance up
> >to see what I wrote last paragraph - and that's purely a function of the limited visual
> >area.  The only thing that will help that is to make the screen bigger - and that
> >clamshell trick is probably about the only practical way to do that to any large 
> >degree.  (Not to mention that it automatically provides screen protection and covers 
> >the buttons!)
> 
> This is a misuse of Palmtops.  They are designed for writing small notes and not for
> writing complete articles.

And so we come full circle.  Remember, my original comment was that palmtops are 
okay for shopping lists and similarly-sized documents, but that they were torturous for 
handling anything larger - and thus, I could not understand the drive to put an XML 
parser in one, much less the whole "Wireless Web" campaign.  See, there is a method to 
my madness....

> Some people are using it to even write programs but that is misuse as well. 

And some people would like to have a very portable way to write - more portable even 
than the average laptop.  I am one of those.  Are you actually saying that my computing 
needs are irrelevant and that nobody should aim a product at this target group?  (FWIW, 
one of my big uses of my palmtop is to jot down things which go into my randomizing 
routines for GOTC - more slogans for the list, fake ad concepts, and so on.  I've even 
been known to write down column ideas in the bathroom.  I'd love to be able to flesh 
those out without having to hook the unit back up to my computer to do so.)
 
> Again, I reiterate my position: slightly larger screen size + higher screen resolution +
> ClearType will increase readability tremendously.  I guarantee that people will get a
> shock come next X-mas.

To what end, though?  If you're just reading stock quotes or a shopping list, who really 
cares what it looks like?  Either the purpose behind that is to enable better reading of 
longer documents (which you characterize as "misuse") or it's just feeping creaturism 
with no point.

> BTW, I think we are off-topic for this list.

Perhaps you are - I still want to know what's behind the "XML in a toaster" imperative, 
and I daresay that's got to be on-topic here.  Like I said at the outset, I've heard a lot of 
talk about *how* to put XML in a cellphone, but nothing at all about *why* to do it.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 24 08:01:44 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:33 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <199911232329888.SM01008@Unknown.>
Message-ID: <000001bf3652$75a79b80$099918d1@docuverse1>

Rev,

>And so we come full circle.  Remember, my original comment was 
>that palmtops are okay for shopping lists and similarly-sized
>documents, but that they were torturous for handling anything
>larger - and thus, I could not understand the drive to put an
>XML parser in one, much less the whole "Wireless Web" campaign.  
>See, there is a method to my madness....

Lets try to avoid the circle this time. <g>

The answer is that there are uses for XML other than documents.

For example, XML-based RPC protocol or XML-based e-commerce
such as trading, auction, billing, etc.  None of these involve
information which fit into traditional definition of documents.

Take a phone for example.  Your front office could send you
some notes in XML format so that if it contains a phone number,
the phone can display a small phone icon at the corner of the
message and make the call for you when you press a button.  Your
business card can be stored on your phone so that you can give
it to another person by simply pointing it at his phone.  Another
use might be to receive address information so that you can find it
using cellular tri-angulation or satellite technology.

>And some people would like to have a very portable way to 
>write - more portable even than the average laptop.  I am
>one of those.  Are you actually saying that my computing 
>needs are irrelevant and that nobody should aim a product at 
>this target group?  (FWIW, one of my big uses of my palmtop
>is to jot down things which go into my randomizing routines
>for GOTC - more slogans for the list, fake ad concepts, and
>so on.  I've even been known to write down column ideas in
>the bathroom.  I'd love to be able to flesh those out without
>having to hook the unit back up to my computer to do so.)

I am not saying your computing needs are irrelevant, just
unrealistic at this time.  Someday your needs will be met,
just not right now.  Please have pity on the poor engineers.

>To what end, though?  If you're just reading stock quotes or a 
>shopping list, who really cares what it looks like?  Either the
>purpose behind that is to enable better reading of longer documents
>(which you characterize as "misuse") or it's just feeping creaturism 
>with no point.

You are changing words on me, Rev.  By 'misuse', I meant using
Palmtops to write long documents, not reading.  The purpose of
increasing screen size and resolution is to make reading more
comfortable and to show more information.

>> BTW, I think we are off-topic for this list.
>
>Perhaps you are - I still want to know what's behind the "XML 
>in a toaster" imperative, and I daresay that's got to be
>on-topic here.  Like I said at the outset, I've heard a lot of 
>talk about *how* to put XML in a cellphone, but nothing at all 
>about *why* to do it.

*sigh*  Sorry about that.  I guess it is not than obvious.  See
above for an example involving cell phones.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sb at metis.no  Wed Nov 24 08:04:43 1999
From: sb at metis.no (Steinar Bang)
Date: Mon Jun  7 17:17:33 2004
Subject: If SAX == lex, then what == yacc?
In-Reply-To: Sean Chen's message of "Tue, 23 Nov 1999 11:38:17 -0500 (EST)"
References: <Pine.LNX.3.96.991123113600.7948A-100000@www.falconwing.com>
Message-ID: <whzow4iacx.fsf@viffer.oslo.metis.no>

>>>>> Sean Chen <schen@falconwing.com>:

> Back on topic, what you're looking for might be done by MDSAX, or
> Coins (whatever it is called nowadays).

Hm...
	http://www.jxml.com/mdsax/
	http://www.jxml.com/coins/
for easy reference.  Interesting!  Especially that MDSAX bit.

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



From larsga at garshol.priv.no  Wed Nov 24 09:03:13 1999
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: Mon Jun  7 17:17:33 2004
Subject: Parser compliance
References: <Sean Mc Grath's message of "Tue, 16 Nov 1999 17:36:19 +0000">  <3.0.6.32.19991116173619.0092d320@gpo.iol.ie> <3.0.6.32.19991117140109.0092f8c0@gpo.iol.ie>
Message-ID: <m366ysw9bj.fsf@ifi.uio.no>


(Sorry for the lateness of this posting.  Due to problems with my
subscription it didn't arrive the first time I tried.)

* Sean Mc Grath
| 
| Fully 1.0 Compliant - Non Validating
| -------------------------------------
| 
| 2. XT

RXP (C, Python) probably belongs here.

| Fully XML 1.0 Compliant - Validating
| ------------------------------------

Java Project X (the Sun parser).

| Non XML 1.0 Compliant - Non-Validating
| --------------------------------------
| nsgmls (C++)
| xmlproc (Python)

xmllib (Python)
sgmlop (Python)
Ælfred (Java) (though David Brownell's version gets pretty close)
xml4j (Java) (now Xerces-Java)
XJParser (Java)
AdvXMLParser (C++)
Markup (Objective Caml)

| Non XML 1.0 Compliant - Validating
| ----------------------------------
| nsgmls (C++)
| xmlproc (Python)

xml4j (Java) (now Xerces-Java)
XJParser (Java)


Should we quantify how many of the tests in the OASIS suite a parser
may fail (excluding those on which the jury is still out)? Given that
there are 1065 tests, what should be considered acceptable?  1065?
1060? 1050?  1000?

Looking at the conformance review on xml.com requiring 1065 and 1060
would only accept the Sun parser, whereas 1050 and 1000 would accept
the Sun parser and XP.

--Lars M.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 24 09:48:55 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:33 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E909C@sohos002.ied-support.net>
Message-ID: <000001bf3661$70a125c0$099918d1@docuverse1>

Don Park wrote:
> We clearly have a need to delve deeper into XML fragments related
> issues and I believe this is one of them.
> 
> In my view, sometimes it makes sense for a particular XML fragment
> to specify constraints on its containers.  By its nature, a fragment
> is likely to be missing some information (parameters if you will) that
> must be provided by the context.  We currently have no mechanism to do
> this but we will need it eventually.

Mark Birbeck replied:
>Not true - XML Fragment Interchange suggests a simple way to 
>do all that you say. I know that current thinking is that there's 'too 
>many specs to read', but this one's a teeny one.>

Mark, I think you misinterpreted the XML Fragment Interchange spec.
It suggest a way to provide context information about a fragment
of an existing document.  I was talking about some means to specify
and constrain where a standalone fragment (meaning that it is not a
complete document and is also not part of another document) may be
used and what context information is needed to use it.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From obecker at informatik.hu-berlin.de  Wed Nov 24 10:46:51 1999
From: obecker at informatik.hu-berlin.de (Oliver Becker)
Date: Mon Jun  7 17:17:33 2004
Subject: Namespaces and Well-formedness
Message-ID: <199911241046.LAA12771@mail.informatik.hu-berlin.de>

Hi there,

this is more a philosophical question ;-)

Is a XML construct like

<ns1:el xmlns:ns1="http://namespace/a" 
        xmlns:ns2="http://namespace/a">
</ns2:el>

well-formed?

Syntactical not -- semantical yes ...

Best regards,
Oliver


/-------------------------------------------------------------------\
|  ob|do        Dipl.Inf. Oliver Becker                             |
|  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
|  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
\-------------------------------------------------------------------/


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



From jimson at india.dharma.com  Wed Nov 24 10:48:17 1999
From: jimson at india.dharma.com (Jimson K John)
Date: Mon Jun  7 17:17:33 2004
Subject: Role of Parser in SAX !!  
Message-ID: <Pine.LNX.4.10.9911241603070.17886-100000@india.dharma.com>


Hi, 

I have some basic doubts regarding the SAX implementation and role of  Parsers.

The documents I referred do not give me a clear picture of the 
functionality of each component. 

The following information is taken from "www.megginson.com/SAX/index.html"

David megginson says,

" To create a very simple Java-based SAX application,
you first need to download and install at least two Java libraries, 
making certain that you add all of them to your CLASSPATH 

  1 the SAX interfaces and classes;
  2 and at least one XML parser that supports SAX (or a parser and a 
    separate third-party SAX driver for it).  "

Is there any document available, which explains the architecture of SAX
implementation and role of "XML Parser", used with the implementation?

Regards,
Jimson



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



From sasha at moldat.co.il  Wed Nov 24 10:57:19 1999
From: sasha at moldat.co.il (Sasha (Moldat))
Date: Mon Jun  7 17:17:33 2004
Subject: Unsubscribe
References: <000001bf3661$70a125c0$099918d1@docuverse1>
Message-ID: <002301bf366a$5bd60850$74195ac2@sasha>




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



From sasha at moldat.co.il  Wed Nov 24 10:57:18 1999
From: sasha at moldat.co.il (Sasha (Moldat))
Date: Mon Jun  7 17:17:33 2004
Subject: Unsubscribe
References: <000001bf3661$70a125c0$099918d1@docuverse1>
Message-ID: <002d01bf366a$8b506bc0$74195ac2@sasha>




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



From sasha at moldat.co.il  Wed Nov 24 10:58:26 1999
From: sasha at moldat.co.il (Sasha (Moldat))
Date: Mon Jun  7 17:17:33 2004
Subject: Unsubscribe
References: <000001bf3661$70a125c0$099918d1@docuverse1>
Message-ID: <005601bf366a$b2247430$74195ac2@sasha>







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



From Andy.Bradbury at syntegra.bt.co.uk  Wed Nov 24 11:25:31 1999
From: Andy.Bradbury at syntegra.bt.co.uk (Andy.Bradbury@syntegra.bt.co.uk)
Date: Mon Jun  7 17:17:33 2004
Subject: facts, conclusions, and exhortations re XML (short)
Message-ID: <65AF45D5E535D2118AFB0008C7FA23180C3E5D@FL-EXCHANGE-03>



Tom Passim wrote

Nice to hear from someone else who has read this little gem.
Amazingly modern-sounding, wasn't it?


I suspect that the relative timelessness of the story is due to the fact
that it is mainly based on an understanding of human psychology.
The sad thing is that whilst technology marches on, it seems our ability to
handle it (pun intended) has advanced very little, if at all, since the
start of the current century.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 24 11:36:08 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:33 2004
Subject: XTech 2000: Call for Papers and Tutorials
Message-ID: <14395.52617.539013.36457@localhost.localdomain>

Together with my co-chairs, Jon Bosak and Tim Bray, I would like to
invite the members of xml-dev to submit proposals for papers and
tutorials at the XTech 2000 conference, which will be held from
February 27 to 2 March 2000 in San Jose, CA.

XTech is sponsored by the GCA and is the major west-coast XML
conference: it has a technical (rather than marketing) focus, and it
is an excellent place for introducing or debating new ideas and
technologies.  For more information about the conference, please see

  http://www.gca.org/attend/2000_conferences/xtech_2000/

Note that the submission deadline of November 30 on the Web page is
incorrect (we'll fix it ASAP); the deadline for both paper and
tutorial proposals is December 8, 1999, with notification by December
30, 1999.


Call for Papers
---------------

Presentations at XTech 2000 will be 30-45 minutes in length or
featured in panel discussion format. Suitable topic areas may include,
but are not limited to the following: Open Source XML, XML inside the
firewall, XML and Non-Roman character sets, XML and portable devices
(palmtops, cell phones, embedded systems), XML and Java, XML and
Python, XML and publishing, XML/EDI XML and e-business, XML and Perl,
Vocabularies, Query languages, Information Content and Exchange (ICE),
Stylesheets, rendering and printing XML and co-existence Web graphics,
Linking Core technology developments, Multipart document packaging,
Schemas XML and ActiveX Authoring, XML and Unicode, Repositories XML
for the individual user, Browsers Developer tools Application
requirements, Transition considerations, and more!

Submissions must be sent electronically to xtech2000@gca.org in a
clear text format that contains the following fields:

Presentation title: 
Presenter's name: 
Job title and affiliation: 
Address: (full mailing address, including postal code) 
Email/Phone/Fax: 
Biography: 
Abstract (not less than 500 words): 
Brief Description: 


Call for Tutorials
------------------

Proposals will be accepted for one or two-day tutorials. Submissions
must be sent electronically to xtech2000@gca.org in a clear text
format that contains the following fields:

Presentation title: 
Presenter's name: 
Job title and affiliation: 
Address: (full mailing address, including postal code) 
Email/Phone/Fax: 
Biography: 
Course outline: 
Brief Description: 
Specific requirements: (pre-requisites, equipment required, special
audio/visual) 

Schedule for Submissions

December 8, 1999 - - - Presentation submission deadline
December 8, 1999 - - - Tutorial submission deadline
December 30, 1999 - - - Notification of acceptance


Thanks, and all the best,


David Megginson,
Co-chair XTech 2000


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



From martind at netfolder.com  Wed Nov 24 12:20:43 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:34 2004
Subject: Test
Message-ID: <NBBBJPGDLPIHJGEHAKBAAEHOEHAA.martind@netfolder.com>

Hi,

I have tested, with XT, an XML document containing an XSLT stylesheet in
accordance to the section 2.7 of the W3C XSLT recommendation (named
"Embedding Stylesheets".

Obviously, when you embed a XSLT stylesheet in the source XML document you
don't need an external stylesheet reference. But, I got the following error
message when I tried to convert an XML document with an XSLT stylesheet
embedded in it.

Error message:
usage: java com.jclark.xsl.sax.Driver source stylesheet [result]
[param=value]...

The command line (on windows, with XT as an executable) which ended with the
above result is :

xt mydoc.xml (I didn't included a XSLT file name in the command line since
the XSLT style sheet is embedded in the XML document.)

Seems that there is a bug. However, I may not have entered the command line
correctly. Did I?

Question: Did somebody else tried the same thing with other XSLT engine.
What kind of result did you got?

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From abcoates at TheOffice.net  Wed Nov 24 12:24:33 1999
From: abcoates at TheOffice.net (Anthony B. Coates)
Date: Mon Jun  7 17:17:34 2004
Subject: If SAX == lex, then what == yacc?
Message-ID: <199911241233.XAA31321@mail.internetezy.com.au>

** Reply to message from Sean Chen <schen@falconwing.com> on Tue, 23 Nov 1999
11:38:17 -0500 (EST)

> > Compilers (traditionally)  don't build a tree
> > version of a source file before they start outputting the object code to
> > a file. 
> 
> Er... minor correction here.  Compilers *do* traditionally build a tree
> version of a source file, it's called the AST, Abstract Syntax Tree. 

OK, what I should more precisely have written is that compilers do not *wait*
until they have finished building an entire tree before they start generating
the object code.  This seems to be to be different to what happens with the DOM,
where the tree would appear to be complete by the time the client application
can access it.

	Cheers,
			Tony.

** Anthony B. Coates    >> mailto:abcoates@TheOffice.net <<
** Software Engineer (Java).  This is a 100% Pure Java e-mail.
** AJUG National Secretary (see http://www.ajug.org.au/)

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



From martind at netfolder.com  Wed Nov 24 13:14:17 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:34 2004
Subject: XML documents and Schemas
Message-ID: <NBBBJPGDLPIHJGEHAKBAMEHOEHAA.martind@netfolder.com>

Hi,

While I was writing about schemas, I was suddenly facing a wall
<aural>imagine a guy standing in front of a wall with the Pink floyd song
"The wall" playing in background :-)<aural>.

How do we link an XML document to its schema?

Does anybody has an answer or should I sing again "I was a rich man..." :-)

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Wed Nov 24 13:40:18 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:34 2004
Subject: Linking a XML document to its schema
Message-ID: <NBBBJPGDLPIHJGEHAKBAMEIAEHAA.martind@netfolder.com>

Hi,

It would make sense to link an XML document or XML fragment to its schema
with the name space reference. For instance, if I would have the following
document:

<mycheck xmlns="http://www.mydomain.com/MyCheckShema.xml">

.... My check content....
<theinvoice xmlns="http://www.domain.com/theinvoice.xml">
...the invoice content....
<theinvoice>
... other content ....

</mycheck>

Then the xmlns attribute URI value would be useful to something other than
feeding XML-dev discussions.

Benefits:
---------
Each fragment can be validated with its schema.
Each fragment is part of a namespace and the name space vocabulary is
defined by a schema.
Contrary with what we got in the SGML world, a document can be freely
aggregated from fragments and still be validated by a validating parser. The
aggregate does not have to centralize the knowledge about the document
structure.
Major benefit: re-use and modularity.

But maybe this is already a work in progress within W3C? If this is the
case, little Rascals, why do you let us sing "if I where a rich man..." by
hiding this secret :-)) Otherwise, may I take the liberty to make this
suggestion (I am modest enough to be sure that you already got this
suggestion from other people too).

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Wed Nov 24 14:03:02 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:34 2004
Subject: Valid XML document
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEIBEHAA.martind@netfolder.com>

Hi,

Is the following XML document a valid XML 1.0 document?

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT test (greeting)>
  <!ELEMENT greeting (#PCDATA)>
]>
<?xml-stylesheet href="#Style" type="text/xsl"?>
<test>
<xsl:stylesheet version="1.0"
			xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<html>
<title>this is a test</title>
<body><xsl:value-of select="//greeting"></body>
</html>
</xsl:stylesheet>
<greeting>Hello, world!</greeting>
</test>

According to the XSLT recommendation section 2.7 it should be. But according
to the XML 1.0 recommendation is it?

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From reschke at medicaldataservice.de  Wed Nov 24 14:26:51 1999
From: reschke at medicaldataservice.de (Julian Reschke)
Date: Mon Jun  7 17:17:34 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAMEIAEHAA.martind@netfolder.com>
Message-ID: <NCBBIPMOPKLLGKJPBINCEELHDFAA.reschke@medicaldataservice.de>


> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Didier PH Martin
> Sent: Wednesday, November 24, 1999 2:37 PM
> To: 'XML Dev'
> Subject: Linking a XML document to its schema
>
>
> Hi,
>
> It would make sense to link an XML document or XML fragment to its schema
> with the name space reference. For instance, if I would have the following
> document:
>
> <mycheck xmlns="http://www.mydomain.com/MyCheckShema.xml">
>
> .... My check content....
> <theinvoice xmlns="http://www.domain.com/theinvoice.xml">
> ...the invoice content....
> <theinvoice>
> ... other content ....
>
> </mycheck>
>
> Then the xmlns attribute URI value would be useful to something other than
> feeding XML-dev discussions.
>
> Benefits:
> ---------
> Each fragment can be validated with its schema.
> Each fragment is part of a namespace and the name space vocabulary is
> defined by a schema.
> Contrary with what we got in the SGML world, a document can be freely
> aggregated from fragments and still be validated by a validating
> parser. The
> aggregate does not have to centralize the knowledge about the document
> structure.
> Major benefit: re-use and modularity.
>
> But maybe this is already a work in progress within W3C? If this is the
> case, little Rascals, why do you let us sing "if I where a rich man..." by
> hiding this secret :-)) Otherwise, may I take the liberty to make this
> suggestion (I am modest enough to be sure that you already got this
> suggestion from other people too).

Nice proposal.

And it's even backed by Microsoft (see MSXML behaviour).



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



From Benoit.PAPILLAULT at geofermat.com  Wed Nov 24 14:39:09 1999
From: Benoit.PAPILLAULT at geofermat.com (Benoit PAPILLAULT)
Date: Mon Jun  7 17:17:34 2004
Subject: processing instructions def.
In-Reply-To: <Pine.LNX.4.10.9911241603070.17886-100000@india.dharma.com>
References: <Pine.LNX.4.10.9911241603070.17886-100000@india.dharma.com>
Message-ID: <11651.991124@opteway.com>


Hello,

I can't find a precise documentation on Processing Instruction, except
on the W3C web server, but it's really not enough. Is there a more
complete definition, along with real samples. I'm trying to implement
some scripting features and 'm very interested in using XML Processing
Instructions.

TIA
Benoit



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 24 14:47:14 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:34 2004
Subject: RDF, again
In-Reply-To: Paul Prescod's message of "Tue, 23 Nov 1999 14:01:00 +0100"
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net>
Message-ID: <m3pux0t0a7.fsf@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> The thing I find confusing about the RDF syntax is that the element
> type name can be either an RDF type name or an RDF property. XML
> makes no distinction and that's why I think that it is difficult to
> use for object oriented interchange. Your example doesn't run into
> that problem really because it only goes one level deep. But what
> does the RDF for this CSS-style object representation look like:
> 
> person{
> 	name: person-name{ first: "Paul"; last: "Prescod"};
> 	address: snail-mail-address{
> 		street: street-address{
> 			number: 5936; 
> 			street: "Lovers Lane"
> 		city: city( #!Dallas );
> 		state: state( #!Texas )};
> 	siblings: #sibling1 #sibling2 #sibling3}
> 
> (curly braces for structures, parentheses for primitive types,
> concatenation for lists, semicolons for property separators)

Without minimization (except for rdf:type as the classname), you get
something like this, which is fully normalized and thus suitable B2B
data exchange:


  <!-- Example 1 of 3 (almost no minimization) -->

  <megg:Person rdf:ID="sibling0">
    <megg:name rdf:resource="#id002"/>
    <megg:address rdf:resource="#id003"/>
    <megg:sibling rdf:resource="#sibling1"/>
    <megg:sibling rdf:resource="#sibling2"/>
    <megg:sibling rdf:resource="#sibling3"/>
  </megg:Person>

  <megg:PersonName rdf:ID="id002">
    <megg:firstName>Paul</megg:firstName>
    <megg:lastName>Prescodd</megg:lastName>
  </megg:PersonName>

  <megg:SnailMailAddress rdf:ID="id003">
    <megg:street rdf:resource="#id005"/>
    <megg:city rdf:resource="http://www.places.org/us/tx/dallas/"/>
    <megg:state rdf:resource="http://www.places.org/us/tx/"/>
  </megg:SnailMailAddress>

  <megg:StreetAddress rdf:ID="id005">
    <megg:number>5936</megg:number>
    <megg:streetName>Lovers Lane</megg:streetName>
  </megg:StreetAddress>


With a bit of minimization (and some denormalization), you get
something like this:


  <!-- Example 2 of 3 (moderate minimization) -->

  <megg:Person rdf:ID="sibling0">
    <megg:name>
      <megg:PersonName>
	<megg:firstName>Paul</megg:firstName>
	<megg:lastName>Prescod</megg:lastName>
      </megg:PersonName>
    </megg:name>
    <megg:address>
      <megg:SnailMailAddress>
	<megg:street>
	  <megg:StreetAddress>
	    <megg:number>5936</megg:number>
	    <megg:streetName>Lovers Lane</megg:streetName>
	  </megg:StreetAddress>
	</megg:street>
	<megg:city rdf:resource="http://www.places.org/us/tx/dallas/"/>
	<megg:state rdf:resource="http://www.places.org/us/tx/"/>
      </megg:SnailMailAddress>
    </megg:address>
    <megg:sibling rdf:resource="#sibling1"/>
    <megg:sibling rdf:resource="#sibling2"/>
    <megg:sibling rdf:resource="#sibling3"/>
  </megg:Person>


With really ferocious minimization, you can get down to this (but you
lose some class names):


  <!-- Example 3 of 3 (maximum minimization) -->

  <megg:Person rdf:ID="sibling0">
    <megg:name firstName="Paul" lastName="Prescod"/>
    <megg:address rdf:parseType="Resource">
      <megg:street number="5936" streetName="Lovers Lane"/>
      <megg:city rdf:resource="http://www.places.org/us/tx/dallas/"/>
      <megg:state rdf:resource="http://www.places.org/us/tx/"/>
    </megg:address>
    <megg:sibling rdf:resource="#sibling1"/>
    <megg:sibling rdf:resource="#sibling2"/>
    <megg:sibling rdf:resource="#sibling3"/>
  </megg:Person>


Certainly, it's easy for a person to read at this level, but it's
quite tricky to process; I'm surprised that several RDF processors
have actually come out.

The RDF committee had to make a difficult choice: to what extent
should they complicate the syntax to help get buy-in from the initial
implementors?

When the original SGML committee had to make that choice, strong
vested interests (especially in publishing, from what I've heard) were
able to force a horrendous complexity on the ISO 8879:1986 grammar.

When the XML committee had to make the same choice, they held they
line much better, but vested interests (especially in the SGML world)
were able to force them to include some kruft like notations and
external unparsed entities.

When the RDF committee had to make the same choice, strong vested
interests (especially in the HTML world) were able to force them to
include heavy optional minimization and a some bizarre kruft like the
rdf:aboutEachPrefix attribute.

No International Standard *or* consortium spec is free from this kind
of horse trading -- it's just a fact of life.  In the end, the kruft
in XML didn't hurt it all that much, while the syntactic kruft in SGML
pretty much did it in.  The jury is still out on RDF syntax, but the
convoluted syntax puts them dangerously close to the edge.

> Note also that common XML usage puts datatypes in the schema or
> elsewhere. To recognize an integer as such you need the schema or some
> other external knowledge. Some DTDs have <int> elements but that's so
> ugly that it hasn't really "caught on." The XML world is very
> inconsistent in its thought about the appropriateness of dependence on
> the schema. I think that that dependence is slowly creeping back into
> vogue.

I think that it was their intention to do so, but they were waiting
for some general XML datatyping facility.

> Speaking on behalf of the devil, I'd say that in one week we could
> define (or just find) an S-expression-like language with none of these
> weaknesses and in less time we could write a parser for it. It could
> have "XML element" as a primary data type for embedded XML and could
> also be embedded IN XML.

Not only could we, but many of us have -- I've written quite a few
thousand lines of LISP in my life, and I know that it works fine for
representing data structures, but nobody uses it.  XML also works
fine, and everyone uses it.  So, let's get on to the interesting
stuff, and actually start doing something with information rather than
just marking it up.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From adrian_north at uk.ibm.com  Wed Nov 24 14:57:19 1999
From: adrian_north at uk.ibm.com (adrian_north@uk.ibm.com)
Date: Mon Jun  7 17:17:34 2004
Subject: Question on Schema/DTD
Message-ID: <80256833.00521088.00@d06mta03.portsmouth.uk.ibm.com>



Hi,

I am new to XML and am busy trying to learn it. I hope someone can help me with
a reqlly stupid question. I am working through the XML: Extensible Markup
Language book by Elliotte Rusty Harold and understand DTDs but have noticed that
Schemas are mentioned on a lot of XML web sites  and on this list as a
replacement for DTDs. Could someone tell me what they are and tell me of some
resources that could help me understand them better.

Many thanks

Adrian

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


Adrian North
Certified Lotus Principal Application Developer
Notes Developer - Service Systems Operations - Domino Development
AL12S,  Alencon House,  Alencon Link,  Basingstoke,  England

Internet : Adrian_North@uk.ibm.com                 Lotus Notes : Adrian
North/UK/IBM
Tel : +44 (0)1256 343302                           Fax : +44 (0)1256 355042
Internal : 313302



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 15:26:34 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:34 2004
Subject: Handheld computers
References: <3.0.32.19991122202035.013167a0@pop.intergate.ca>
Message-ID: <383C0271.12081968@prescod.net>

Tim Bray wrote:
> 
> Hey, I'm as Palm-Pilot-addicted as the next geek.  But I have yet
> to see anything that I can stick in my pocket that has any chance
> of replacing aforesaid general-purpose computer.   

Nobody claimed that palm computers were going to replace PCs. David
said:

 I do think that small devices will be at the centre of
> computing in the next decade (and a mostly MS-free centre, to boot).

The phrase that set of this hubub is vague enough that one could argue
that it is already true. How many MIPS are expended worldwide in
figuring out when to deploy air bags, at what temperature to microwave
pop-corn, switch cells, decode DVDs, unscramble satellite symbols and so
forth.

As the buzzheads at Comdex say: it's the PC *plus* era.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 15:28:53 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:35 2004
Subject: Namespaces and Well-formedness
Message-ID: <3.0.32.19991124072805.014e78e0@pop.intergate.ca>

At 11:46 AM 11/24/99 +0100, Oliver Becker wrote:
>Is a XML construct like
>
><ns1:el xmlns:ns1="http://namespace/a" 
>        xmlns:ns2="http://namespace/a">
></ns2:el>
>
>well-formed?

No. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From klarlund at research.att.com  Wed Nov 24 16:07:13 1999
From: klarlund at research.att.com (Nils Klarlund)
Date: Mon Jun  7 17:17:35 2004
Subject: ANNOUNCEMENT: DSD - a new schema notation related to XSLT and CSS
Message-ID: <yqz2r9hfq3ex.fsf@fish-ha.research.att.com>


A Document Structure Description (DSD) is a new and very effective way
of describing XML documents.  This new schema language is result of a
research collaboration between AT&T Labs, NJ and BRICS at the
University of Aarhus, Denmark.  The DSD language has arisen out of a
need to describe XML documents to Web programmers with an elementary
background in computer science.  DSDs have also been expressively
designed to further W3C sponsored XML technologies such as Cascading
Style Sheets (CSS) and XSL Transformations (XSLT).

CSS is an essential part of modern HTML, but has so far not been
formulated as a general style sheet mechanism for XML that works with
any semantic domain.  DSDs provide both a generalized semantics for a
CSS-like style sheet mechanism and document processing instructions
that provide the abstraction benefits of CSS in any XML document.

XSLT 1.0 is a programming notation that allows transformations of
classes of XML documents into semantic domains like HTML.  XSLT
programs are easy to write, especially if assumptions can be made
about the input documents.  The expressive power of DSDs allow
declarative and readable specifications of XML documents that are to
be subjected to XSLT processing.

DSDs require no specialized XML/SGML insights.  The technology is
based on general and familiar concepts that allow much stronger
document descriptions than possible with DTDs or the current XML
Schema proposal.  

For more information, please go to the DSD Web site:

  http://www.brics.dk/DSD

We already offer

- a detailed, complete, and tested DSD 1.0 language description

- an introductory article

- free source code

- a meta-DSD that completely accounts for the syntax of DSDs

- an XSLT pretty-printer that converts DSDs into hyper-link HTML

- a preliminary industrial case report, where we discuss the use of
  DSD to describe XPML, a variation on HTML for interactive voice
  services


We are encouraging comments and suggestions for further development!


Nils Klarlund, AT&T Research
Anders Møller, BRICS
Michael I. Schwartzbach, BRICS






xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Wed Nov 24 16:15:54 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:35 2004
Subject: Handheld computers
References: <3.0.32.19991122202035.013167a0@pop.intergate.ca> <383C0271.12081968@prescod.net>
Message-ID: <009d01bf3697$2ebd9040$d5d88dce@sagus.com>


----- Original Message -----
From: Paul Prescod <paul@prescod.net>
To: <xml-dev@ic.ac.uk>
Sent: Wednesday, November 24, 1999 10:21 AM
Subject: Handheld computers


>  I do think that small devices will be at the centre of
> > computing in the next decade (and a mostly MS-free centre, to boot).
>
> The phrase that set of this hubub is vague enough that one could argue
> that it is already true.

And to nudge things back on-topic, will typical "post-PC devices" need XML
(broadly defined) support?  Will they come with XML 1.0 parsers?  Are they
too memory or CPU constrained to fully utilize XML 1.0? Would having
something like SML standardized improve the chances for "XML-like" tools
being used on Post-PC devices?

There seem to be a range of points of view:

1 - Yes, Post-PD Devices need something like SML because they *will* process
(not just display) data and every byte/cycle is precious on such limited
devices.  If the XML community does not help standardize a simplified subset
of XML, then the vendors will go off in their own directions and it will be
chaos.

2 - Yes, but XML 1.0 is perfectly well suited for Post-PC devices because
it's not really all that bloated and/or the devices will soon have all the
power that an XML 1.0 processor would need.  Bifurcating the XML standard
would lead to chaos.

3 - No, the question is moot.  Just because some these devices support
specialized XML-based languages such as WML doesn't mean that the devices
themselves will need more generalized XML tools; it will all be done on the
server side where there is power to spare.  SML is pointless, and Don Park
will be eating paper for breakfast when he comes to his senses.

I personally lean toward 1), but could be persuaded of 2 ... but it's going
to be hard to convince me that CDATA sections and external parsed entities
are anything better than a necessary evil on a handheld! I think 3) is wrong
for the future (although it is clearly today's reality) because historically
devices get "smarter", and today's display-only WML phones will evolve
toward more intelligent message-processing devices.

Thoughts?




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 24 16:28:09 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:35 2004
Subject: processing instructions def.
In-Reply-To: Benoit PAPILLAULT's message of "Wed, 24 Nov 1999 15:38:45 +0100"
References: <Pine.LNX.4.10.9911241603070.17886-100000@india.dharma.com> <11651.991124@opteway.com>
Message-ID: <m3ln7nua6j.fsf@localhost.localdomain>

Benoit PAPILLAULT <Benoit.PAPILLAULT@geofermat.com> writes:

> I can't find a precise documentation on Processing Instruction, except
> on the W3C web server, but it's really not enough. Is there a more
> complete definition, along with real samples. I'm trying to implement
> some scripting features and 'm very interested in using XML Processing
> Instructions.

They're a black box.  In SGML, a processing instruction is just a
bunch of text, with no predefined meaning; in XML, the processing
instruction is a name followed optionally by a bunch of text, also
with no predefined meaning.  That means that an application should
look at a processing instruction and (usually) ignore it if it doesn't 
seem to make sense.

Of course, this isn't very robust, and there have been two suggestions 
for improvements:

1. The old XML WG considered allowing PI targets to be
   Namespace-qualified, but in the end there wasn't enough demand, and 
   the shift to attribute-based NS declarations would have killed that 
   anyway.

2. Various people have suggested following a lead from recent SGML
   developments and requiring the PI target to be a notation name.
   Since notations are almost never used in the XML world, that might
   be a non-starter.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Wed Nov 24 16:39:39 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:35 2004
Subject: Valid XML document
In-Reply-To: <383BFA0F.2A9F698@goshawk.com>
Message-ID: <NBBBJPGDLPIHJGEHAKBAOEIGEHAA.martind@netfolder.com>

Hi Steve,

Steve said:
It's not "valid" under XML 1.0 because you haven't included DTD definitions
for
<xsl:stylesheet>, <html>, or any of the other elements or attributes in the
stylesheet.

It shouldn't work for XSL because your DTD hasn't defined an ID attribute
for
<xsl:stylesheet>, and the <xsl:stylesheet> in this document doesn't have
"Style" as its value
of that ID attribute. So the fragment identifier "#Style" doesn't point to
anything.

Didier reply:
You are right, the id attribute is missing in the stylesheet element. So the
right document should be:
> <?xml version="1.0" encoding="UTF-8" ?>
> <!DOCTYPE greeting [
>   <!ELEMENT test (xsl:stylesheet, greeting)>
>   <!ELEMENT greeting (#PCDATA)>
> ]>
> <?xml-stylesheet href="#Style" type="text/xsl"?>
> <test>
> <xsl:stylesheet version="1.0"
>                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>			id="Style">
> <html>
> <title>this is a test</title>
> <body><xsl:value-of select="//greeting"></body>
> </html>
> </xsl:stylesheet>
> <greeting>Hello, world!</greeting>
> </test>

So, the document, to be valid in accordance to the xml 1.0 recommendation,
and if we want to parse it with validation, would have to be like above.

In the SGML world we would have
> <!DOCTYPE greeting [
>   <!ELEMENT test 	- - (xsl:stylesheet, greeting)>
>   <!ELEMENT greeting 	- - (#PCDATA)>
> ]>
> <?xml version="1.0" encoding="UTF-8" ?>
> <?xml-stylesheet href="#Style" type="text/xsl"?>
> <test>
> <xsl:stylesheet version="1.0"
>                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>			id="Style">
> <html>
> <title>this is a test</title>
> <body><xsl:value-of select="//greeting"></body>
> </html>
> </xsl:stylesheet>
> <greeting>Hello, world!</greeting>
> </test>

The difference is not big except that I would need to provide a declaration
to the SGML parser so that the document could be parsed/validated.

So the actual XML 1.0 recommendation consider that the scope of validation
with a DTD is the whole document. As for SGML I cannot aggregate document
fragment with their own structure definition in order to compose an
aggregate document. "The whole has to be aware of the parts" he said with
the tone of a disappointed person. If we would have an aggregation
mechanism, the whole wouldn't need to be aware of the part and the document
could still be parsed and validated.

I guess that the XML world or the SGML world has to follow the same
evolution as procedural languages did:
a) phase 1: monolithic programs - monolithic documents
b) phase 2: modular programs - modular documents

A Possible evolution of the document specie: an object being the aggregation
of behaviors and data structure. Behaviors are stand alone fragments with
their own structure and validation process, data structure also. An object
can be composed by aggregating both. Hoops, I went too far, we're not even
at phase 2 yet. Slow down Didier :-))

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 17:08:03 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:35 2004
Subject: processing instructions def.
References: <Pine.LNX.4.10.9911241603070.17886-100000@india.dharma.com> <11651.991124@opteway.com> <m3ln7nua6j.fsf@localhost.localdomain>
Message-ID: <016e01bf369e$763e24a0$eb020a0a@bowstreet.com>

> 1. The old XML WG considered allowing PI targets to be
>    Namespace-qualified, but in the end there wasn't enough demand, and
>    the shift to attribute-based NS declarations would have killed that
>    anyway.
>
> 2. Various people have suggested following a lead from recent SGML
>    developments and requiring the PI target to be a notation name.
>    Since notations are almost never used in the XML world, that might
>    be a non-starter.

But, as I've argued many times, the whole notation mechanism is *very*
similar to namespaces anyway. Both notations and namespaces involve a
mapping of a local name to a universal identifier. The only real difference
is that namespaces are used to make element and attribute names universal
and notations are used to make PI targets, unparsed entity content types and
PCDATA content types universal.

Compare:

<... xmlns:fop="http://xml.apache.org/fop/">
...
<fop:foo>...</fop:foo>

to

<!NOTATION fop SYSTEM "http://xml.apache.org/fop/">
...
<?fop bar?>

Exactly the same principal. Different mechanism.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lauren at sqwest.bc.ca  Wed Nov 24 17:14:04 1999
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:17:35 2004
Subject: Handheld computers
In-Reply-To: <009d01bf3697$2ebd9040$d5d88dce@sagus.com>
Message-ID: <199911241710.JAA30391@mail.sqwest.bc.ca>

On 24 Nov 99, at 11:15, Michael Champion wrote:

>  it's going
> to be hard to convince me that CDATA sections and external parsed entities
> are anything better than a necessary evil on a handheld! 

Are there any web sites out there that use external entities 
anyway? In other words, does anyone use them unless they're 
sure the clients can support them? (Given that non-validating 
processors don't need to process external entities).


Lauren

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



From matthew at praxis.cz  Wed Nov 24 18:14:14 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:35 2004
Subject: Handheld computers
References: <3.0.32.19991122202035.013167a0@pop.intergate.ca> <383C0271.12081968@prescod.net> <009d01bf3697$2ebd9040$d5d88dce@sagus.com>
Message-ID: <383C2A5A.D795302C@praxis.cz>

You forgot:

4 - CDATA is redundant, entities are a less elegant solution to various
problems that could be solved with XLink and/or schemas, processing
instructions and comments would be better structured using normal markup
and notations are just weird mime types. These features increase
complexity without adding significant value and only found their way
into XML in the first place because certain vested interests wanted them
to ease the migration path from SGML to XML. SML will let the market
decide whether it wants these features, and once we discover that very
few people do then we can rename it XML 2.0 and be rid of them forever.

Not that I subscribe to this view or anything. ;-)

Matt

Michael Champion wrote:
<snip/>
> 1 - Yes, Post-PD Devices need something like SML because they *will* process
> (not just display) data and every byte/cycle is precious on such limited
> devices.  If the XML community does not help standardize a simplified subset
> of XML, then the vendors will go off in their own directions and it will be
> chaos.
> 
> 2 - Yes, but XML 1.0 is perfectly well suited for Post-PC devices because
> it's not really all that bloated and/or the devices will soon have all the
> power that an XML 1.0 processor would need.  Bifurcating the XML standard
> would lead to chaos.
> 
> 3 - No, the question is moot.  Just because some these devices support
> specialized XML-based languages such as WML doesn't mean that the devices
> themselves will need more generalized XML tools; it will all be done on the
> server side where there is power to spare.  SML is pointless, and Don Park
> will be eating paper for breakfast when he comes to his senses.
<snip/>

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



From martind at netfolder.com  Wed Nov 24 18:54:17 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:35 2004
Subject: Valid XML document
In-Reply-To: <383C1EE6.6D0036D0@goshawk.com>
Message-ID: <NBBBJPGDLPIHJGEHAKBAGEIMEHAA.martind@netfolder.com>

Hi Steve

I noticed what you are saying when I tried the small doc in a XML parser.
Sorry, I responded too fast without doing double checking on the doc.
Anyway, thanks for bringing rigor to the message.

Nevertheless the problem with validating a document composed of fragments is
still open and DTDs are not the solution like we both demonstrated ;-).

Also, we can take here the opportunity to mention that section 2.7 of the
XSLT recommendation can potentially lead to misinterpretation by including a
DTD in the example. By doing so, as Steve demonstrated so well, we would
have to include any element and attribute definition about the document.
This would include of course all our elements + the XSLT elements used. It
would be better to use as example a simple well formed document instead of a
document including a DTD. This suggestion may improve the XSLT
recommendation's quality.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

----------
Steve said:
You're still missing one thing for XSL to work :)

    <!ATTLIST xsl:stylesheet    id ID #REQUIRED>

The "#Style" fragment identifier can't find the element whose id is "Style"
if
it doesn't know which attributes are of type ID. Adding this ATTLIST will
give
the parser the needed information--it should work even for a non-validating
parser.

Regarding XML 1.0 validation, your new version is still not a "valid" XML
document--it's only well-formed. It's not sufficient to add xsl:stylesheet
to
the content model of <title>. You have to add separate <!ELEMENT>
definitions
for "xsl:stylesheet", "xsl:value-of", "html", "title", "body". You also have
to
add <!ATTLIST> definitions for all attributes that these new element types
use.
Your DTD will be fairly large by the time you finish. If you want to embed
the
stylesheet in the document, you will probably want to give up being "valid",
and
accept being just "well-formed".

Another validity violation, not very serious but still a violation, is that
the
DOCTYPE element type should be "test" rather than "greeting".

For example, here's how the DOCTYPE of your document might look if you
really
wanted it to be completely valid--pardon my mistakes:

    <!DOCTYPE test [
        <!ELEMENT test (xsl:stylesheet, greeting)>
        <!ELEMENT greeting (#PCDATA)>
        <!ELEMENT xsl:stylesheet (html)>
        <!ELEMENT html (title, body)>
        <!ELEMENT title (#PCDATA)>
        <!ELEMENT body (xsl:value-of)>
        <!ELEMENT xsl:value-of EMPTY>
        <!ATTLIST xsl:stylesheet
                version CDATA #REQUIRED
                xmlns:xsl CDATA #REQUIRED
                id ID #REQUIRED>
        <!ATTLIST xsl:value-of
                select CDATA #REQUIRED>
    ]>


Didier PH Martin wrote:

> Didier reply:
> You are right, the id attribute is missing in the stylesheet element. So
the
> right document should be:
> > <?xml version="1.0" encoding="UTF-8" ?>
> > <!DOCTYPE greeting [
> >   <!ELEMENT test (xsl:stylesheet, greeting)>
> >   <!ELEMENT greeting (#PCDATA)>
> > ]>
> > <?xml-stylesheet href="#Style" type="text/xsl"?>
> > <test>
> > <xsl:stylesheet version="1.0"
> >                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> >                       id="Style">
> > <html>
> > <title>this is a test</title>
> > <body><xsl:value-of select="//greeting"></body>
> > </html>
> > </xsl:stylesheet>
> > <greeting>Hello, world!</greeting>
> > </test>
>
> So, the document, to be valid in accordance to the xml 1.0 recommendation,
> and if we want to parse it with validation, would have to be like above.

--
- Steve Dahl
sdahl@goshawk.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Wed Nov 24 19:22:10 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:35 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NCBBIPMOPKLLGKJPBINCEELHDFAA.reschke@medicaldataservice.de>
Message-ID: <NBBBJPGDLPIHJGEHAKBAAEIOEHAA.martind@netfolder.com>

Hi Julian,

Julian said:
And it's even backed by Microsoft (see MSXML behaviour).

Didier reply:
Is this what  you where referring to:

XML Schemas and Namespaces

----------------------------------------------------------------------------
----

Internet Explorer 5 enables XML Schemas to be referenced directly from a
namespace declaration. This allows the XML parser to validate the XML
against the grammar defined in the schema. It also allows the object model
to expose data types and to allow navigation to the schema document through
the definition property (see XML Schemas and the DOM).

A namespace declaration can reference a schema by including the URL to the
schema document prefaced by the "x-schema:" string. For example, to
reference an XML Schema for books from an XML file conforming to this
schema, you would write:

<book xmlns="x-schema:http://www.microsoft.com/xml/schema/book.xml">
  <title>Presenting XML</title>
  <author>Richard Light</author>
  <pages>334</pages>
</book>
Here the default namespace refers to the sample book grammar used in the
Defining Elements and Attributes section. The namespace URI is prefixed with
"x-schema:" to indicate to the XML parser that there is a schema
corresponding to this namespace, with the location corresponding to the
remainder of the Universal Resource Identifier (URI). The schema will be
loaded and the document will be validated.


----------------------------------------------------------------------------
----

What I have not tried though, is if the following document will be parsed
and validated by MSXML. Did you tested something similar? if yes what was
the result?

<book xmlns="x-schema:http://www.microsoft.com/xml/schema/book.xml">
  <title>Presenting XML</title>
  <author>Richard Light</author>

  <inclusion
xmlns="x-schema:http://www.mydomain.com/xml/schema/inclusion.xml">
  <greeting>happy thanksgiving</greeting>
  </inclusion>

  <pages>334</pages>
</book>

Thanks for your comment
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 19:31:23 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:35 2004
Subject: Gates on XML & other stuff
Message-ID: <3.0.32.19991124113142.01418680@pop.intergate.ca>

  http://www.informationweek.com/762/gates.htm

The XML stuff is in sections 3 & 4, but it's all worth reading. -T.

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



From Patrice.Bonhomme at loria.fr  Wed Nov 24 19:48:09 1999
From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme)
Date: Mon Jun  7 17:17:35 2004
Subject: XLink within a DTD ?
Message-ID: <199911241948.UAA08767@chimay.loria.fr>


Hi,

I am just looking for some samples of DTD that are using the last WD of XLink. 
Any ?

Thanks,
PAt.

-- 
  ==============================================================
   bonhomme@loria.fr      Tel : 03 83 59 30 52 / 06 11 34 03 85
   http://www.loria.fr/~bonhomme                 Office : B.228
  --------------------------------------------------------------
   * Serveur Silfide  : http://www.loria.fr/projets/Silfide
  ==============================================================



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



From jes at kuantech.com  Wed Nov 24 20:12:47 1999
From: jes at kuantech.com (Jeffrey E. Sussna)
Date: Mon Jun  7 17:17:35 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAMEIAEHAA.martind@netfolder.com>
Message-ID: <000001bf36b7$5a11bc10$0f36a8c0@quokka.com>

As I understand it, there is nothing PREVENTING you from doing this. In
fact, RDF does in fact (I think) use namespaces this way. I think the
problem came from the fact that the namespace facility does not INHERENTLY
make any connection between content and schema. A namespace attribute could
point off into the Delta quadrant, as long as it points to a unique planet
within the delta quadrant.

Jeff

> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk
> [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Didier PH Martin
> Sent: Wednesday, November 24, 1999 5:37 AM
> To: 'XML Dev'
> Subject: Linking a XML document to its schema
>
>
> Hi,
>
> It would make sense to link an XML document or XML fragment
> to its schema
> with the name space reference. For instance, if I would have
> the following
> document:
>
> [ snip ]
>


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



From iand at fdc.co.uk  Wed Nov 24 20:51:54 1999
From: iand at fdc.co.uk (Ian Davis)
Date: Mon Jun  7 17:17:35 2004
Subject: XSLT Processors for C
Message-ID: <6870.991124@fdc.co.uk>


On Tuesday, November 23, 1999, 10:07:53 AM, Niels wrote:

> What XSLT processors exists out there, that I can use from C (or
> perhaps C++)?
You could have a look at Transformiix, which is part of the Mozilla
project. Not sure of it's compliance level, but it's probably a frew
drafts out of date.
(http://lxr.mozilla.org/mozilla/source/extensions/transformiix)


Infoteria also make a C++ processor.
(http://www.infoteria.com/en/contents/download/index.html)

The Apache Group recently announced plans to release a C++ version of
the XALAN processor some time in the (far?) future
http://xml.apache.org/xalan/index.html


Ian

-- 
WAPAW.COM Wireless Portal - http://wapaw.com/
Internet Alchemy - http://InternetAlchemy.org/
StartsHere - http://theweb.startshere.net/




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 21:11:31 1999
From: schen at falconwing.com (Sean Chen)
Date: Mon Jun  7 17:17:35 2004
Subject: program to restore end tags?
Message-ID: <Pine.LNX.3.96.991124160037.28138A-100000@www.falconwing.com>

Hi everyone,

Someone mentioned recently on this list a program to restore minimized
SGML end tags, but I lost the message and can't find it again.

I'm trying to write a simple SGML->XML converter which will do as much as
possible without being a full-fledged SGML parser.

Alternatively, if anyone has such a beast let me know =)

. . . 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Wed Nov 24 22:10:43 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:36 2004
Subject: Linking a XML document to its schema
In-Reply-To: <000001bf36b7$5a11bc10$0f36a8c0@quokka.com>
Message-ID: <NBBBJPGDLPIHJGEHAKBAAEJCEHAA.martind@netfolder.com>

Hi Jeff,

Jeff said:
As I understand it, there is nothing PREVENTING you from doing this. In
fact, RDF does in fact (I think) use namespaces this way. I think the
problem came from the fact that the namespace facility does not INHERENTLY
make any connection between content and schema. A namespace attribute could
point off into the Delta quadrant, as long as it points to a unique planet
within the delta quadrant.

Didier reply:
This is precisely my concern. Actually the name space URI is used for nearly
nothing because it may point, as you said, to the delta quadrant and this
would not be of no importance. If the URI would instead point to a schema
reference and that the schema reference would have as scope the same scope
as the name space has, then, a validating parser could validate the document
composed of diverse fragments.

So, in this case, among the XML problems we would have:

1 - XML document to style sheet linkage (resolved)
2 - XML fragment to style sheet linkage (unresolved and undefined as
specified the scope is the whole document)
3 - XML document linkage with schemas (resolved if name space URI points to
schemas)
4 - XML fragment linkage to schemas (resolved if name space URI points to
schemas and that the schema scope is the same as the name space scope)
5 - XML document linkage to its metadata (unresolved - if the RDF format
could be used to associate metadata to XML documents)
6 - XML fragment linkage to its metadata (unresolved - if the RDF format
could be used to associate metadata to XML documents)

I could say however that if 3 and 4 are resolved then 5 and 6 also.

However, there should be also provision to be able to include a schema in
the document instead of having it defined externally. So, something like

<MyFragment xmlns="#mySchema">
<xml:schema id="MySchema">
....Schema content here ....
</xml:schema>
...fragment content here ...
</myFragment>

I used xml:schema so that this element is also part of a namespace and to be
cautious about the fact that a particular vocabulary main contain also this
same name. Also, because a Schema defines an XML document and therefore it
make sense that schemas are part of this name space.

The good point about linking a schema to a name space is that I can include
other fragments owned by other name spaces and the document could still be
valid and be parsed by a validating parser.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jes at kuantech.com  Wed Nov 24 22:23:00 1999
From: jes at kuantech.com (Jeffrey E. Sussna)
Date: Mon Jun  7 17:17:36 2004
Subject: URI's in namespaces
Message-ID: <000401bf36c9$844c1bd0$0f36a8c0@quokka.com>

Not to rouse the fitfully sleeping namespace beast, but I can't get it out
of my mind. In particular, I have a dumb question:

If the namespace facility designers were adamant that a namespace identifier
doesn't necessarily point to any actual schema, then why did they use URI's
as namespace "targets". The whole notion of URI implies that there's
something (i.e., the resource) out there. But a namespace is not inherently
a pointer (regardless of whether you can access the thing pointed to). Why
not just make namespace targets ordinary XML names?

Jeff Sussna


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 22:59:43 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun  7 17:17:36 2004
Subject: URI's in namespaces
In-Reply-To: <000401bf36c9$844c1bd0$0f36a8c0@quokka.com>
Message-ID: <Pine.GHP.4.21.9911242237230.9614-100000@mail.ilrt.bris.ac.uk>

On Wed, 24 Nov 1999, Jeffrey E. Sussna wrote:

> Not to rouse the fitfully sleeping namespace beast, but I can't get it out
> of my mind. In particular, I have a dumb question:
> 
> If the namespace facility designers were adamant that a namespace identifier
> doesn't necessarily point to any actual schema, then why did they use URI's
> as namespace "targets". The whole notion of URI implies that there's
> something (i.e., the resource) out there. But a namespace is not inherently
> a pointer (regardless of whether you can access the thing pointed to). Why
> not just make namespace targets ordinary XML names?

On the Web, everything of value and interest has a URI so we can talk
about it. That's just the Web information model. Some URIs encode
meta-information about how to connect to a service to find out more
about (and possible acquire views or renderings of) the named resource.

The relationship between URIs and "bags of bits" is not as
simple as is often implied within the namespace debates.

A URI is more than simply a pointer to a bag of bits. The Web makes it
easy to think of URIs in this way, but usually there's something more
complex and subtle going on.

Content negotiation is the classic example:

http://www.w3.org/Icons/WWW/w3c_main is the name of a resource. That
resource is an 'abstract' thing (a logo) without an intrinsic byte-stream
representation of its own. That abstract named work, the logo, has
concrete manifestations in two other name-able resources, w3c_main.gif
and w3c_main.png. 

Because the identifier for the abstract resource encodes information
sufficient to put clients in touch with an authoritative service that
knows about that resource, we can "ask the Web" for information about
w3c_main. Current HTTP/1.1 is a bit hacky in this
respect, but does have the notion of content-negotiation, exploited
below. 

If a web client does an HTTP GET on w3c_main you'll get a bag of
bytes, since the machinery will figure out that you're after one of the 
content-negotiable renderings. If however you send a HEAD message to
www.w3.org's HTTP server, qualified with an "Accept" mimetype preference
asking for a non-existant rendering of the resource, you'll get a bunch
of metadata back.

Here's an HTTP session transcript where I ask for info about a
(non-existent) rendering of the logo resource, which prompt Apache to
spill some details about the versions that are available.

	[danbri]$ telnet www.w3.org 80
	Trying...
	Connected to www.w3.org.
	Escape character is '^]'.
	HEAD /Icons/WWW/w3c_main HTTP/1.1
	Host: 127.0.0.1
	Accept: application/x-fictitious-mimetype
 
	HTTP/1.1 406 Not Acceptable
	Date: Wed, 24 Nov 1999 22:42:53 GMT
	Server: Apache/1.3.6 (Unix) PHP/3.0.11
	Alternates: {"w3c_main.png" 0.7 {type image/png} {length 5904}},
	{"w3c_main.gif" 0.5 {type image/gif} {length 5684}}
	Vary: negotiate, accept
	TCN: list
	Content-Type: text/html


What does this show? That an globally unique name for something is
useful, and that the abstract name can map onto multiple
(metadata-described) mime-typed bags of bits  that are also resource
with URIs,  and that we have protocols in place to ask the Web about
both abstract and bytestreamable resources, and to negotiate access to the latter.  

It does not follow from the fact that we name something 'http:*' that it
is a Web page, or that it has only a single manifestation on the network
as a load of bits, or that you have the right to access any or all of those
bytestream renderings. Dereferencing being a privilege not a right and
all that...

I could create an XML vocabulary, name it (say) 'http://xmlns.com/foo',
and configure my server to understand content-negotiated GET and HEAD
requests. This doesn't make 'http://xmlns.com/foo' a simple pointer to a
mimtyped bytestream. While the resource (an abstract work, _just like_
the W3C logo http://www.w3.org/Icons/WWW/w3c_main) is certainly "out
there" in some sense, the fact that we can (when the wind is blowing in
the right direction, network is up, access control is liberal etc etc)
ask an HTTP server about that abstract resource is a feature not a bug.

Dan


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 24 23:56:42 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:36 2004
Subject: XML:  Still Just HypedWebStuff
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain>
Message-ID: <383C1863.6CE3@hiwaay.net>

David Megginson wrote:
> 
> Not only could we, but many of us have -- I've written quite a few
> thousand lines of LISP in my life, and I know that it works fine for
> representing data structures, but nobody uses it.  XML also works
> fine, and everyone uses it.  

Actually, no.  It just looks like that from the chair.  Most proposals 
I see still accept and endorse CSV.  If you try to deliver XML to 
the FBI for NIBRS, for example, they will send it back to you and say, 
"Try again.  No certification."  Seems they are heavily invested 
in some new tech on old tech.  

> So, let's get on to the interesting
> stuff, and actually start doing something with information rather than
> just marking it up.

Hmm.  Maybe not so fast.  Got to do that cost analysis first.

I think if we actually look at a lot of server sites, we will find 
relational databases, eg, SQLServer, Oracle, etc., doing some 
variant of ASP slicing and dicing of recordsets, wrapping them 
in HTML, and sending them back.  All of the ads in the paper 
here look for ColdFusion authors, etc.  So, sure, there may 
be advantages to XML, but they are still more hyped than 
realized.  Right now, XML is still the newKidOnTheBlock, 
trendy, but unproven.

We have a few more years of waiting for stable 
platforms, and the DoJ case just pushed that out a little 
further.  Are we quickly heading back to the same market 
and community conditions that beset CALS:  lots of agreements, 
separated by miles of NIH water. consultants who get fat but 
systems that aren't compatible, pronouncements of the 
next new thing, and conferences where the consultants 
flock around the newest toy?

I wish it weren't so, but all the discussion of SML assures 
me it is.  What we have is a more complete toolset than 
we have ever had, cheaper tools, a simpler spec that is 
made complex by the family of spawning application languages,
so just as heavy and just as hard to learn by the majority if 
a little more palatable to the hardcore parser junkies, 
and industries still unconvinced that the performance is 
realizable, or that their razor thin margins can be sustained 
when shoppers see the price everytime they put something in 
the virtual cart, and have no incentive to impulse buy.

The Kroger online shopping experiment is fascinating.  They 
did it here in Huntsville.  The published results were that 
it wasn't well accepted; the unpublished *comments* are that 
when you let them out of the store without passing the 
Enquirer counter, they don't buy, and there goes the margins. 
Again, to quote my boss at GE in the Eighties, "All this 
visibility f**ks up the game."  Took me a long time to 
figure out what he meant:  if the capital flow lessens, 
the quality subsides concurrently. 

Ask yourself why ANY good technical VP responsible for the 
bottom line of his company implements a technology that 
costs more to implement and maintain owing to the instability of the 
platforms, has to be sold for less given the hyped perception of 
ease and ubiquity, and in the end, gives moreorless the same 
results as the relational system and CSV?

Cost justify XML. 

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Wed Nov 24 23:54:31 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:36 2004
Subject: program to restore end tags?
In-Reply-To: <Pine.LNX.3.96.991124160037.28138A-100000@www.falconwing.com>
Message-ID: <Pine.GSU.4.10.9911241553410.3493-100000@netcom17.netcom.com>

On Wed, 24 Nov 1999, Sean Chen wrote:
> Someone mentioned recently on this list a program to restore minimized
> SGML end tags, but I lost the message and can't find it again.
> 
> I'm trying to write a simple SGML->XML converter which will do as much as
> possible without being a full-fledged SGML parser.
> 
> Alternatively, if anyone has such a beast let me know =)

James Clark's sgmlnorm, part of the SP package, should do the trick.



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



From crism at exemplary.net  Thu Nov 25 01:04:13 1999
From: crism at exemplary.net (Christopher R. Maden)
Date: Mon Jun  7 17:17:36 2004
Subject: program to restore end tags?
Message-ID: <v01530500b4623ae42336@[209.157.134.39]>

[Sean Chen]
>Someone mentioned recently on this list a program to restore minimized
>SGML end tags, but I lost the message and can't find it again.

sgmlnorm, as someone already pointed out, or spam (SP Add Markup), which
are both part of SP (<URL:http://www.jclark.com/sp/>).

>I'm trying to write a simple SGML->XML converter which will do as much as
>possible without being a full-fledged SGML parser.

But if you're going to use one of those, you might as well use SX, from the
same package.  It *is* (well, incorporates) a full-fledged SGML parser, but
so do the other two utilities.

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111



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



From martind at netfolder.com  Thu Nov 25 01:47:30 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:36 2004
Subject: About XML document linkage and Schemas.
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEJGEHAA.martind@netfolder.com>

Hi,

Don Box sent me a very good comment about XML fragment/document linkage to
their schemas.

Comment:
---------
That is one approach discussed in the Schema WG composition task force
report (http://www.w3.org/TR/1999/WD-xmlschema-1-19990924/composition-t
f.html). The current schema WD does not specify which (if any) of these
approaches will be used unfortunately.

BTW, overloading the xmlns attribute to locate schema docs would break
a lot of existing XML (most of my xmlns URIs have been UUIDs lately) in
addition to making it more difficult to compare two elements for type
equivalence. I am all for using a well-known XML attribute per element
to associate schema with instances, but I don't think overloading the
existing xmlns attribute is a good idea.

Didier reply:
-------------
Don is right, we have, in the field, several documents using diverse URI for
name space references. things like

URN, URL, etc..

These URI are not necessarily resolvable into a location and a schema
document stored at this place. Thus, we are still in front of the wall: How
to link an XML fragment to its schema?
And in the same vein: how do we link a document to its meta data?

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 03:29:53 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:36 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAMEIAEHAA.martind@netfolder.com>
Message-ID: <001101bf36f5$aadc1260$099918d1@docuverse1>

Didier wrote:
>It would make sense to link an XML document or XML fragment to 
>its schema with the name space reference.

Wrong path, Didier.  If you want to do this, use another
attribute or element.  Namespace with schemas often go
together but not always.  Just ask the HTML WG.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 04:12:41 1999
From: schen at falconwing.com (Sean Chen)
Date: Mon Jun  7 17:17:36 2004
Subject: program to restore end tags?
In-Reply-To: <v01530500b4623ae42336@[209.157.134.39]>
Message-ID: <Pine.LNX.3.96.991124230032.90B-100000@www.falconwing.com>

Hi everyone,

On Wed, 24 Nov 1999, Christopher R. Maden wrote:

> [Sean Chen]
> >Someone mentioned recently on this list a program to restore minimized
> >SGML end tags, but I lost the message and can't find it again.
> 
> sgmlnorm, as someone already pointed out, or spam (SP Add Markup), which
> are both part of SP (<URL:http://www.jclark.com/sp/>).
> 
> >I'm trying to write a simple SGML->XML converter which will do as much as
> >possible without being a full-fledged SGML parser.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thanks everyone who replied, but I already know of SX, sgmlnorm, etc. etc.
Just recently on this list someone posted a link to a C program that did
the trick, only I can't find it.

I really don't want to parse SGML fully, as it's not needed for an
SGML->XML converter.  I just want to assume concrete syntax, leave the
entities alone, and the more esoteric SGML documents I might encounter
I'll fob off to SX or something more industrial strength.

. . . 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 04:27:12 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:36 2004
Subject: URI's in namespaces
References: <000401bf36c9$844c1bd0$0f36a8c0@quokka.com>
Message-ID: <00a301bf36fc$84aaae60$0300000a@cygnus.uwa.edu.au>

> If the namespace facility designers were adamant that a namespace
identifier
> doesn't necessarily point to any actual schema, then why did they use
URI's
> as namespace "targets". The whole notion of URI implies that there's
> something (i.e., the resource) out there. But a namespace is not
inherently
> a pointer (regardless of whether you can access the thing pointed to). Why
> not just make namespace targets ordinary XML names?

IMO, the problem is not with the namespace design of using URIs, but the
practice of using HTTP URLs. A few people, myself and Paul Prescod included,
have independently suggested a URL scheme just for naming.
It would take the same format as an HTTP URL so it would leverage off the
DNS, but its scheme would clearly indicate it is a name.

So a namespace for FOP stuff might be hname://xml.apache.org/fop/

Some have argued that there is no practical difference between a document
that describes the thing and the thing itself. I can buy this for things
like specifications (where the document doesn't just describe, but defines).
But for some things, like people, that are being assigned HTTP URLs for use
with RDF, I think you bump into problems if you also put a document at that
URL describing the thing. Why? Because assertions about the thing might not
hold for the document about the thing. The Dublin Core "Creator" for the
resource would probably be different depending on whether the resource was
the person or the document describing the person. So there is a need to
distinguish.

Of course, there is the whole "what the name of the song is called vs what
the song is called vs what name of the song is vs what the song is" :-)

James Tauber


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 05:53:56 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:37 2004
Subject: Linking a XML document to its schema
In-Reply-To: <001101bf36f5$aadc1260$099918d1@docuverse1>
Message-ID: <Pine.GSU.4.10.9911242152290.15102-100000@netcom7.netcom.com>

On Wed, 24 Nov 1999, Don Park wrote:

> Didier wrote:
> >It would make sense to link an XML document or XML fragment to 
> >its schema with the name space reference.
> 
> Wrong path, Didier.  If you want to do this, use another
> attribute or element.  Namespace with schemas often go
> together but not always.  Just ask the HTML WG.

How about a pr*c*ss*ng *nstr*ct**n instead?



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



From varun at chennai.tcs.co.in  Thu Nov 25 06:07:59 1999
From: varun at chennai.tcs.co.in (V Arun Kumar)
Date: Mon Jun  7 17:17:37 2004
Subject: unsubscribe
Message-ID: <65256834.0021843D.00@MAILSERVER2.chennai.tcs.co.in>



unsubscribe



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 06:24:59 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:37 2004
Subject: Linking a XML document to its schema
In-Reply-To: <Pine.GSU.4.10.9911242152290.15102-100000@netcom7.netcom.com>
Message-ID: <000101bf370e$21e52b40$099918d1@docuverse1>

>How about a pr*c*ss*ng *nstr*ct**n instead?

I really think it would be simpler to just use
an element and damn the sentiments over 'main
document structure'.  I prefer:

<xml:schema href="http://www.foo.bar/schemas/ecom">

over

<?xml:schema href="http://www.foo.bar/schemas/ecom"?>

Most of the APIs out there does not offer any parsing
support for PI data.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 08:37:09 1999
From: oren at capella.co.il (Oren Ben-Kiki)
Date: Mon Jun  7 17:17:37 2004
Subject: ANNOUNCEMENT: DSDs a new schema language supporting XSLT 
References: <yqz2ln7o5462.fsf@fish-ha.research.att.com>
Message-ID: <08da01bf371e$87ff5f30$4602a8c0@capella.co.il>

DSD has specified as one of its goals:

"... expressive power of DSDs should be close to that of XSLT ..."

This raises the question of why not to use XSLT directly, now that we have
the <xsl:message> construct (a document is valid if and only if applying the
XSLT "schemasheet" does not invoke any <xsl:message> calls).

Admittedly DSD's syntax is nicer, but it isn't clear to me that the same
effect can't be achieved with a "standard schema template library" for XSLT.
Such library could provide services for "schemasheets" - for example, some
sort of regular expression support. In the worst case, maybe adding a small
number of basic constructs to XSLT for this purpose might be required; isn't
this better then inventing a whole new language?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From crism at exemplary.net  Thu Nov 25 08:41:53 1999
From: crism at exemplary.net (Christopher R. Maden)
Date: Mon Jun  7 17:17:37 2004
Subject: program to restore end tags?
Message-ID: <v01530500b462a337c52e@[209.157.134.1]>

[Sean Chen]
>I really don't want to parse SGML fully, as it's not needed for an
>SGML->XML converter.  I just want to assume concrete syntax, leave the
>entities alone, and the more esoteric SGML documents I might encounter
>I'll fob off to SX or something more industrial strength.

I think you'll have a sort of halting problem, unless you're dealing with a
known set of documents.

For a start, it's really hard to add end-tags without parsing the DTD, so
you're most of the way to a full parser right there.  But you won't know if
the concrete syntax is different unless you parse the SGML declaration; you
won't know what shortrefs may be in effect unless you parse the DTD; you
won't know what could be inside an entity (since SGML doesn't have XML's
guarantee that any entity will be an integer of elements); you won't know
what the value of any marked section keyword parameter entities are unless
you've parsed the DTD; etc.  In other words, I think you'll need a full
SGML parser to know if you need a full SGML parser.

On the other hand, if you're dealing with a set of documents whose complete
geneology you know, then you can work with something smaller.  But SX works
and it's reasonably fast, so unless you're in an embedded processor
environment or something, I don't really see a need to re-invent the wheel.

-Chris

--
Christopher R. Maden, Solutions Architect
Exemplary Technologies
One Embarcadero Center, Ste. 2405
San Francisco, CA 94111



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



From reschke at medicaldataservice.de  Thu Nov 25 08:48:53 1999
From: reschke at medicaldataservice.de (Julian Reschke)
Date: Mon Jun  7 17:17:37 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAAEIOEHAA.martind@netfolder.com>
Message-ID: <NCBBIPMOPKLLGKJPBINCKEMNDFAA.reschke@medicaldataservice.de>


> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Didier PH Martin
> Sent: Wednesday, November 24, 1999 8:19 PM
> To: reschke@medicaldataservice.de; 'XML Dev'
> Cc: Stefan Eissing
> Subject: RE: Linking a XML document to its schema
> 
> 
> Hi Julian,
> 
> Julian said:
> And it's even backed by Microsoft (see MSXML behaviour).
> 
> Didier reply:
> Is this what  you where referring to:
> 
> XML Schemas and Namespaces

Yes.

> ...

> What I have not tried though, is if the following document will be parsed
> and validated by MSXML. Did you tested something similar? if yes what was
> the result?
> 
> <book xmlns="x-schema:http://www.microsoft.com/xml/schema/book.xml">
>   <title>Presenting XML</title>
>   <author>Richard Light</author>
> 
>   <inclusion
> xmlns="x-schema:http://www.mydomain.com/xml/schema/inclusion.xml">
>   <greeting>happy thanksgiving</greeting>
>   </inclusion>
> 
>   <pages>334</pages>
> </book>

I haven't used that yet, but this is supposed to work.

Note that the two schema files this is referring to do not exist though...

 

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



From reschke at medicaldataservice.de  Thu Nov 25 08:57:16 1999
From: reschke at medicaldataservice.de (Julian Reschke)
Date: Mon Jun  7 17:17:37 2004
Subject: Linking a XML document to its schema
In-Reply-To: <000101bf370e$21e52b40$099918d1@docuverse1>
Message-ID: <NCBBIPMOPKLLGKJPBINCAEMODFAA.reschke@medicaldataservice.de>

> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Don Park
> Sent: Thursday, November 25, 1999 7:27 AM
> To: 'XML Dev'
> Subject: RE: Linking a XML document to its schema
>
>
> >How about a pr*c*ss*ng *nstr*ct**n instead?
>
> I really think it would be simpler to just use
> an element and damn the sentiments over 'main
> document structure'.  I prefer:
>
> <xml:schema href="http://www.foo.bar/schemas/ecom">
>
> over
>
> <?xml:schema href="http://www.foo.bar/schemas/ecom"?>
>
> Most of the APIs out there does not offer any parsing
> support for PI data.

But then -- if you do not associate the schema with a namespace -- how do
you mix elements from different namespaces / schemas in one document without
breaking validation?



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



From xml at dlsi.ua.es  Thu Nov 25 09:03:33 1999
From: xml at dlsi.ua.es (Cuenta de correo del Xml)
Date: Mon Jun  7 17:17:37 2004
Subject: unsubscribe xml@dlsi.au.es
Message-ID: <199911250900.KAA31501@altea.dlsi.ua.es>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 09:22:50 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NCBBIPMOPKLLGKJPBINCAEMODFAA.reschke@medicaldataservice.de>
Message-ID: <000501bf3726$f5d00980$099918d1@docuverse1>

>But then -- if you do not associate the schema with a 
>namespace -- how do you mix elements from different
>namespaces / schemas in one document without breaking
>validation?

Julian,

I do not see the problem you are describing.  Care to
elaborate with an example?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From matthew at praxis.cz  Thu Nov 25 09:21:50 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:38 2004
Subject: XML:  Still Just HypedWebStuff
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain> <383C1863.6CE3@hiwaay.net>
Message-ID: <383CFF04.56BA9193@praxis.cz>

Len Bullard wrote:
<snip>
> Ask yourself why ANY good technical VP responsible for the
> bottom line of his company implements a technology that
> costs more to implement and maintain owing to the instability of the
> platforms, has to be sold for less given the hyped perception of
> ease and ubiquity, and in the end, gives moreorless the same
> results as the relational system and CSV?
> 
> Cost justify XML.

This is interesting argument, but:

1) It is far from clear that XML solutions will have to be sold for less
because of "hyped perception of ease and ubiquity". My experience is
that people are willing to pay more for XML when the advantages are made
clear to them (and it helps to have the press screaming from the
rooftops about how this is the Next Big Thing). As far as
commoditization is concerned: there is an interesting article in the
Economist this week that disputes this claim (at
http://www.economist.com/editorial/freeforall/current/index_fn2500.html).
Their conclusions seem to be borne out in fact. People would rather shop
at Amazon, where they know the interface, like the features and trust
the vendor, than save $2 and shop at an anonymous vendor competing only
on price. It's true that as XML becomes more prevalent the way people
shop on the Web will change radically, but it is a safe bet that vendors
will continue to find ways other than price to differentiate their
offers.

2) Do you really think that XML gives the same results as an RDBMS and
CSV? Just to give one example, if I have a PHP/ColdFusion/ASP/whatever
site delivering HTML and I suddenly discover that I need to support WAP
(or Ariba Network or PDF or...) I am forced to reimplement everything
and then maintain my two (or three or four) versions in parallel. If I
go for an XML-based solution, then much of my site logic can be drawn up
out of the RDBMS into the XML layer, and the step to the various
delivery formats is only a transformation away. Saving time means saving
money, how's that for a cost justification?

Nevertheless, there is a need for people to start implementing stuff and
establishing a community where schemas, stylesheets and the like can be
"discovered" rather than developed from scratch whenever needed. We also
need more and better tools, especially on the authoring side. The
investment in getting an XML-based solution up and running is relatively
high, and even the subsequent leverage that this provides will pay back
this investment relatively quickly. There's a real risk that
out-of-the-box solutions will appear that provide only a portion of the
potential added value of XML but are so easy to implement and deploy
that they edge more powerful approaches out of the market. Something to
be scared about.

Matthew

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



From matthew at praxis.cz  Thu Nov 25 09:27:40 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:38 2004
Subject: XML Application Servers
Message-ID: <383D0074.24083D68@praxis.cz>

A question: who out there is developing applications delivering XML from
a server platform? How are you doing it? I'm very curious to know
whether developers are favoring:

1) Template-based XML document generation a la PHP
2) Programmatic XML document generation in Java, Perl, C++ or whatever.
3) Hybrid template/programmatic servers like Enhydra/XMLC
4) Commercial XML servers focusing on e-commerce (e.g. Bluestone)
5) Proprietary database environments with XML delivery support (e.g.
Oracle)
6) Delivery from native XML repositories (POET CMS, Tamino, etc.)

It would be very interesting to see if a consensus is already forming
about the Right Way to build XML server apps.

Thanks in advance,
Matthew

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



From reschke at medicaldataservice.de  Thu Nov 25 10:36:40 1999
From: reschke at medicaldataservice.de (Julian Reschke)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
In-Reply-To: <000501bf3726$f5d00980$099918d1@docuverse1>
Message-ID: <NCBBIPMOPKLLGKJPBINCKENBDFAA.reschke@medicaldataservice.de>

> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Don Park
> Sent: Thursday, November 25, 1999 10:25 AM
> To: 'XML Dev'
> Subject: RE: Linking a XML document to its schema
>
>
> >But then -- if you do not associate the schema with a
> >namespace -- how do you mix elements from different
> >namespaces / schemas in one document without breaking
> >validation?
>
> Julian,
>
> I do not see the problem you are describing.  Care to
> elaborate with an example?

Maybe I have misunderstood something...

My understanding is that namespaces are here to give us the power to mix
different vocabularies within one XML document, for instance mixing XSL
statements with HTML output in a stylesheet.

An XML schema (again, my understanding) defines rules how a validating XML
parser can validate constraints on the document structure. If an element
content is "open", I am free to add other elements, in particular elements
from a different namespace. For instance, xsl:template might have an open
content model and allow to insert any kind of tags, for example a
<html:title>. However the title tag itself can only contain character data
(I guess :-).

So it seems it is best to have one XML schema reference per namespace that
is in use in the document, right? My impression was that this wouldn't work
with the proposal you made...








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



From ht at cogsci.ed.ac.uk  Thu Nov 25 10:49:56 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
In-Reply-To: "Julian Reschke"'s message of "Thu, 25 Nov 1999 09:56:11 +0100"
References: <NCBBIPMOPKLLGKJPBINCAEMODFAA.reschke@medicaldataservice.de>
Message-ID: <f5bg0xuvoa7.fsf@cogsci.ed.ac.uk>

[Various sensible questions and suggestions about instance->schema
linking, namespaces, etc.]

The XML Schema WG has been working VERY hard on these difficult
questions, and the next public working draft will contain a detailed
set of facilities for instance-schema linking, schema aggregation and
validation for documents with multiple namespaces.

This pros and cons of dereferencing namespace URIs as raised in this
thread were very much part of our deliberations.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From martind at netfolder.com  Thu Nov 25 11:51:37 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
In-Reply-To: <000101bf370e$21e52b40$099918d1@docuverse1>
Message-ID: <NBBBJPGDLPIHJGEHAKBAOEJOEHAA.martind@netfolder.com>

Hi Don,

An element is OK especially if this element is identified as part of the xml
namespace. We can then have either:

<xml:schema href="http://www.foo.bar/schemas/ecom"/>

or

<xml:schema>
...schema content here ...
</xml:schema>

idem for meta data reference

<rdf:RDF hRef="http://www.foo.bar/schemas/ecom"/>

or

<rdf:RDF>
...meta data content here ...
</rdf:RDF>

This has the merit to be simple, easy to use and remember and most of all -
it has a coherent rule.

I added the "/" at the end of the element. Is it like that in SML when you
have a singleton element?

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
Don Park
Sent: Thursday, November 25, 1999 1:27 AM
To: 'XML Dev'
Subject: RE: Linking a XML document to its schema


>How about a pr*c*ss*ng *nstr*ct**n instead?

I really think it would be simpler to just use
an element and damn the sentiments over 'main
document structure'.  I prefer:

<xml:schema href="http://www.foo.bar/schemas/ecom">

over

<?xml:schema href="http://www.foo.bar/schemas/ecom"?>

Most of the APIs out there does not offer any parsing
support for PI data.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Thu Nov 25 12:05:02 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
In-Reply-To: <f5bg0xuvoa7.fsf@cogsci.ed.ac.uk>
Message-ID: <NBBBJPGDLPIHJGEHAKBACEJPEHAA.martind@netfolder.com>

Hi Henry,

Henry said:
he XML Schema WG has been working VERY hard on these difficult
questions, and the next public working draft will contain a detailed
set of facilities for instance-schema linking, schema aggregation and
validation for documents with multiple namespaces.

This pros and cons of dereferencing namespace URIs as raised in this
thread were very much part of our deliberations.

Didier reply:
Thanks for the info. We look forward reading this new working draft.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 12:14:34 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
Message-ID: <8DCB90532FF7D211B34400805FD48853ADA9C4@SENMAIL3>

This seems to work OK - tested in IE5.

steven
 <<portfolio-schema.xml>>  <<STOCK.XML>>  <<portfolio-schema2.xml>> 

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Julian Reschke [SMTP:reschke@medicaldataservice.de]
> Sent:	25 November 1999 08:48
> To:	Didier PH Martin; 'XML Dev'
> Cc:	Stefan Eissing
> Subject:	RE: Linking a XML document to its schema
> 
> 
> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> > Didier PH Martin
> > Sent: Wednesday, November 24, 1999 8:19 PM
> > To: reschke@medicaldataservice.de; 'XML Dev'
> > Cc: Stefan Eissing
> > Subject: RE: Linking a XML document to its schema
> > 
> > 
> > Hi Julian,
> > 
> > Julian said:
> > And it's even backed by Microsoft (see MSXML behaviour).
> > 
> > Didier reply:
> > Is this what  you where referring to:
> > 
> > XML Schemas and Namespaces
> 
> Yes.
> 
> > ...
> 
> > What I have not tried though, is if the following document will be
> parsed
> > and validated by MSXML. Did you tested something similar? if yes what
> was
> > the result?
> > 
> > <book xmlns="x-schema:http://www.microsoft.com/xml/schema/book.xml">
> >   <title>Presenting XML</title>
> >   <author>Richard Light</author>
> > 
> >   <inclusion
> > xmlns="x-schema:http://www.mydomain.com/xml/schema/inclusion.xml">
> >   <greeting>happy thanksgiving</greeting>
> >   </inclusion>
> > 
> >   <pages>334</pages>
> > </book>
> 
> I haven't used that yet, but this is supposed to work.
> 
> Note that the two schema files this is referring to do not exist though...
> 
>  
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: portfolio-schema.xml
Type: application/octet-stream
Size: 1009 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991125/180f0c09/portfolio-schema.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STOCK.XML
Type: application/octet-stream
Size: 375 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991125/180f0c09/STOCK.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: portfolio-schema2.xml
Type: application/octet-stream
Size: 168 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991125/180f0c09/portfolio-schema2.obj
From gustaf_larsson at hp.com  Thu Nov 25 12:52:09 1999
From: gustaf_larsson at hp.com (gustaf_larsson@hp.com)
Date: Mon Jun  7 17:17:38 2004
Subject: XSL Recommendation
Message-ID: <H0000cf206c9e8f7@MHS>

Hi,

Does anybody know when the final recommendation for the XSL language might 
happen?

Thanks Gustaf
 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 12:59:41 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:38 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
References: <199911232329888.SM01008@Unknown.>
Message-ID: <383CF678.F0FB16B1@prescod.net>

rev-bob@gotc.com wrote:
> 
> Perhaps you are - I still want to know what's behind the "XML in a toaster" imperative,
> and I daresay that's got to be on-topic here.  Like I said at the outset, I've heard a lot of
> talk about *how* to put XML in a cellphone, but nothing at all about *why* to do it.

XML is a way of representing information. Not books or tomes, but
information. From shopping lists to holy texts. Stock quotes to
novellas.

Cell phones must increasingly deal with structured information.
Therefore cell phones need to deal with XML.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 12:59:36 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:38 2004
Subject: RDF, again
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain>
Message-ID: <383CF674.BC7493D5@prescod.net>

David Megginson wrote:
> 
> Not only could we, but many of us have -- I've written quite a few
> thousand lines of LISP in my life, and I know that it works fine for
> representing data structures, but nobody uses it.  XML also works
> fine, and everyone uses it.  So, let's get on to the interesting
> stuff, and actually start doing something with information rather than
> just marking it up.

But we haven't got around to marking it up. We haven't got around to
defining a syntax that we all agree upon for encoding structured
property/value pairs. The heavily minimized version of your example is
easy to read in the traditional XML sense but it is very hard to puzzle
out the RDF graph for it. The uniminized one is great for machine to
machine but not at all appropriate for anything humans would work with.
Why do we have to choose?

Markup is a tool. When it gets in the way, we should replace it.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.aldridge at informatix.co.uk  Thu Nov 25 13:24:03 1999
From: john.aldridge at informatix.co.uk (John Aldridge)
Date: Mon Jun  7 17:17:38 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NBBBJPGDLPIHJGEHAKBACEJPEHAA.martind@netfolder.com>
References: <f5bg0xuvoa7.fsf@cogsci.ed.ac.uk>
Message-ID: <3.0.6.32.19991125132326.00c23d70@mailhost>

>The XML Schema WG has been working VERY hard on these difficult
>questions, and the next public working draft will contain a detailed
>set of facilities for instance-schema linking, schema aggregation and
>validation for documents with multiple namespaces.
>
>This pros and cons of dereferencing namespace URIs as raised in this
>thread were very much part of our deliberations.

Let me explain a problem...

We are developing an application which will use XML as a syntax for
communicating data between two parts of that application.

This XML uses a DTD, both for the (admittedly limited) validation it
provides, and to supply default values for attributes, so the receiving
part of the application needs to be able to find the DTD before it can make
sense of the XML.

Many of the customers for this application will not have live internet
connections, so the DTD needs to be available on the local machine.  Even
if they did have a connection, pulling a 40 KB DTD down over a slow link is
unattractive.

I thought the right answer was going to be to put something like:

   <!DOCTYPE Linestyle PUBLIC
      "-//IDN informatix.co.uk//My Application DTD//EN"
      "http://www.informatix.co.uk/MyApp.dtd"
   >

in the XML file, and then arrange for installation of the software to make
the appropriate entry for "-//IDN informatix.co.uk//My Application DTD//EN"
in the catalogue.  The XML would then be meaningful on any machine on which
the appropriate catalogue entry had been created, or failing that on any
machine with an internet connection.

However, the XML spec makes the resolution of public identifiers optional;
and it seems that support for them is absent from many XML parsers
(including the Microsoft DOM, which I'm trying to use).

What should I do?  If I put:

   <!DOCTYPE Linestyle SYSTEM "file://C:/MyApp/MyApp.dtd">

in the file, the XML will be unusable on any machine which happens to have
installed my application in another directory.

I guess there are a few possible answers to this:

(a) I'm an idiot, and I've missed some obvious solution to this problem.

(b) I'm an idiot, the validation support is not good enough to be worth
having, and default attribute values are at least as evil as external
parsed entities :-)

(c) Yes this is a real problem with DTDs, but at least schemas will have
some better answers to the problem (this is the reason I'm contributing to
this thread).

I'd be grateful for any light which can be shed.
-- 
Cheers,
John

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 13:31:55 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:38 2004
Subject: RDF, again
In-Reply-To: Paul Prescod's message of "Thu, 25 Nov 1999 09:42:28 +0100"
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain> <383CF674.BC7493D5@prescod.net>
Message-ID: <m3zow2r952.fsf@localhost.localdomain>

Paul Prescod <paul@prescod.net> writes:

> But we haven't got around to marking it up. 

Do you mean XML or RDF in particular?  I was referring to XML, which
is coming along very well -- see
http://www.oasis-open.org/cover/xml.html#applications.
is that we stop worrying about the low-level lexical details of markup
and start worrying about higher-level issues like object exchange
(RDF, XMI, or what-have-you).

> The heavily minimized version of your example is easy to read in the
> traditional XML sense but it is very hard to puzzle out the RDF
> graph for it. The uniminized one is great for machine to machine but
> not at all appropriate for anything humans would work with.  Why do
> we have to choose?

Because that's the nature of information exchange.  Any
fully-normalized information is going to be hard to read, because
you're going to have to jump around following the links; any
fully-denormalized information is going to be hard to process.

I don't know if RDF should have tried to deal with both situations in
the same spec (probably not), but switching low-level syntax from tags
to parentheses is hardly going to affect the fundamental problem.
Machines and people eat information differently.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 13:35:39 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:17:39 2004
Subject: XLink within a DTD ?
In-Reply-To: <199911241948.UAA08767@chimay.loria.fr>
References: <199911241948.UAA08767@chimay.loria.fr>
Message-ID: <19991125083531.M1005@w3.org>

On Wed, Nov 24, 1999 at 08:48:00PM +0100, Patrice Bonhomme wrote:
> 
> Hi,
> 
> I am just looking for some samples of DTD that are using the last WD of XLink. 
> Any ?

  You can have a look at the SVG DTDs, they use at least the simple
links parts.
   http://www.w3.org/TR/SVG/svgdtd.html

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 13:38:48 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:39 2004
Subject: XML Application Servers
References: <383D0074.24083D68@praxis.cz>
Message-ID: <050201bf374a$e446b550$1918ccce@murphy>

The right way to develop XML server apps is with Frontier: ;->

http://frontier.userland.com/

Dave


----- Original Message -----
From: Matthew Gertner <matthew@praxis.cz>
To: XML Developers List <xml-dev@ic.ac.uk>
Sent: Thursday, November 25, 1999 1:25 AM
Subject: XML Application Servers


> A question: who out there is developing applications delivering XML from
> a server platform? How are you doing it? I'm very curious to know
> whether developers are favoring:
>
> 1) Template-based XML document generation a la PHP
> 2) Programmatic XML document generation in Java, Perl, C++ or whatever.
> 3) Hybrid template/programmatic servers like Enhydra/XMLC
> 4) Commercial XML servers focusing on e-commerce (e.g. Bluestone)
> 5) Proprietary database environments with XML delivery support (e.g.
> Oracle)
> 6) Delivery from native XML repositories (POET CMS, Tamino, etc.)
>
> It would be very interesting to see if a consensus is already forming
> about the Right Way to build XML server apps.
>
> Thanks in advance,
> Matthew
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 15:46:23 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:39 2004
Subject: Handheld computers
References: <3.0.32.19991122202035.013167a0@pop.intergate.ca> <383C0271.12081968@prescod.net> <009d01bf3697$2ebd9040$d5d88dce@sagus.com> <383C2A5A.D795302C@praxis.cz>
Message-ID: <383D4D46.3F085FA3@prescod.net>

> These features increase
> complexity without adding significant value and only found their way
> into XML in the first place because certain vested interests wanted them
> to ease the migration path from SGML to XML.

Even if you are right that those features do not add significant value
(and various people would debate you about any particular one of them),
it is hardly fair to propose XLink and schemas as replacements when they
were hardly gleams in our eyes three years ago. Most of XML's extra
features went in not because of established interests but rather because
they were known solutions to known problems and we did not have the
courage to presume that solutions would become readily available. The
millenium approaches and it turns out that the solutions still do not
exist in standardized forms. Both XLink and schemas are still in the lab
and both groups are trying desperately to REDUCE their responsibility
for replacing existing XML features, not INCREASE it.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 15:46:19 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:39 2004
Subject: URI's in namespaces
References: <000401bf36c9$844c1bd0$0f36a8c0@quokka.com>
Message-ID: <383D59B9.EDF684D1@prescod.net>

"Jeffrey E. Sussna" wrote:
> 
> Not to rouse the fitfully sleeping namespace beast, but I can't get it out
> of my mind. In particular, I have a dumb question:
> 
> If the namespace facility designers were adamant that a namespace identifier
> doesn't necessarily point to any actual schema, then why did they use URI's
> as namespace "targets". The whole notion of URI implies that there's
> something (i.e., the resource) out there. But a namespace is not inherently
> a pointer (regardless of whether you can access the thing pointed to). Why
> not just make namespace targets ordinary XML names?

There is a reason. I claim it is not a good enough reason, but there is
a reason nevertheless.

 * in order to globally differentiate names we need a globally managed
namespace.
 * we could use phone numbers, but they aren't very "Internet friendly"
 * the next obvious choice is domain names
 * the problem is that in a domain the size of ibm.com (or aol.com!!),
you could still have clashing names
 * but AOL already has an infrastructure for managing its URI namespace
 * so if we use URIs, we can build on that infrastructure

I feel that there is an intrinsic flaw in this whole argument.

The reason we traditionally manage our URI namespace is because we want
to manage the description of retrievable resources. Therefore, if we USE
our pre-existing URI infrastructures then we will always come up with
URIs that look suspiciously (and confusingly) like URLs. They will
always be based on domain names and we know that domain names change
hands. 

If we DO NOT use these infrastructures, then we can come up with more
persistent, less confusing namespaces, but then we've lost the whole
benefit of using URIs! For instance, there is no reason that we should
use http://www.w3.org/1999/XSL/Transform instead of the less confusing
www.w3.org.1999.xsl.transform since neither one really follows the W3Cs
website structure ANYHOW.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Like most religious texts, the XML 1.0 spec has proven itself 
internally-inconsistent, so we're going to have to invent some kind of 
exegetical method now to show how it's really all an allegory." - Anon

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 16:15:08 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:39 2004
Subject: Gates on XML & other stuff
References: <3.0.32.19991124113142.01418680@pop.intergate.ca>
Message-ID: <383C7A60.2C2C@hiwaay.net>

Tim Bray wrote:
> 
>   http://www.informationweek.com/762/gates.htm
> 
> The XML stuff is in sections 3 & 4, but it's all worth reading. -T.

Interesting.  Gates discovers the science of logistics.  Good.  

"CEOs should have a notebook full of every paper form in the company and
an explanation of what the
 plan is to get rid of that form. He doesn't have to understand
technology.."

True.  At the CEO level.  Below that, beware.  Good e-comm engineering
even 
with standard components still requires something akin to standard
systems 
methods.  It is still a transform to the new system and in that, the
reliability 
measures determine how much information is preserved.   The issue going
in is 
how much information is worth preserving, and that starts the fight. 
Without a 
method and means to declare closure, it is a business process that lasts
too long.
By the time one gets it done, the opportunity to use it passes. 
Synchronizing 
the process and events of multiple teams becomes a game of crack the
whip.  Some 
of the teams get it; others are overcome by it because the binding order
favors 
the teams with resources and will to convert.  So, the method must
divide the 
initialization of the base policy set from the negotation of the
contracted 
peformance.  In easy terms, screenwriters then actors.

He states then:

"We don't know how to run a communication company. We don't do that.
We're just 
partners and supporters of the people who are going to make those big
investments."

Scary.  The markup approach is communications:  negotation of contract.  
Declare the goal of the negotiation, then agree on the event schedule
and 
the types.  However, if you need a method, beware the "spinkle tags
through 
documents".  To be efficient, negotiated types require external
agreement and 
sprinkling tags is not how one achieves that.  It is a way some learn
how tags w
ork, but ultimately, rock solid and legally binding contract
negotiations require 
predesigned types.   These are the libraries.  The lag time is the time
to 
convert to these.   That will take a while and is a stone of sysyphus
really. 
But, Sysyphus is paid to keep rocking; he grows a ponytail and becomes
Cousin IT. 

"There's going to be so many standards, so how do you map from one XML
schema 
to another schema?"

BizTalk is what that is but only in that BizTalk is a repository.  So 
is OASIS or any other language services server.  Automated negotiation 
services is the logical evolution of that.

The methods of negotiation based on the goal requirements are the means 
to premap XML schemas.  Agree in advance which preformed types
aggregate, 
in what order, and sometimes, frequency and range.

"It's not just records but it's the whole process and the events in 
that process. How do you build products and standards that digitize
that?"

You're not killing Cousin IT.  You provide products so Cousin IT can do
what he does
better.  You make is such that the tools the other professionals use
are easily integrated to the servers the ITs are setting up.  

Pre-aggregate.  An early negotiation in the business process is engaging
the 
notations to be used at each step of the process, that is, which events
call 
which notations.  Declare the valid namespaces for that document.  In
DTDs, 
one declared a list of notations and data attributes for notations.  We
threw that away 
in XML.  Turn's out, we need them.  Notations let you declare the
component, 
any standard values to pass, and gave you a name for referring to the
process. 

A system where the components map to standard notations (in the long
run, 
any XML application languages is just a notation) requires the ability
to 
test conformance.   Otherwise, there is no meaningful definition of 
reliability MTBF (Mean Time Between Failure).

"Making your business ready for the Internet--that involves security,
exchanging
documents externally, policy-based management. Reliability... it's
probably
the one that drives the sales the most...Reliability is a statistical
phenomenon.."

Reliability has to declared at the component/notation handler level.  
Microsoft's 
biggest drawback is dll management.  It is where the system is hardest
to 
field and share.  Anyone dealing with forms that cache GUIDs sees this
quickly. 
XML can't fix that except to say, if the notation is a PUBLIC notation, 
the user can get another object.  It must interoperate in the
framework.  
Microsoft's challenge is to ensure that interoperation of conformant 
components.... regardless of who declares the namespace in the file. 
The PUBLIC id is the signature of the information.   You agree to 
reliably process information so signed.

To succeed in this, Microsoft needs more than XML.  XML doesn't work 
unless component-level reliability is ensured.  That is what we 
contract for.  The vendor who can get higher reliability ratings 
gets the disk space.   Again, XMLs only real advantage is that from
packet  
to purse, it all goes easier if the parse is common.

len bullard
intergraph public safety



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 16:14:56 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:39 2004
Subject: XML:  Still Just HypedWebStuff
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain> <383C1863.6CE3@hiwaay.net> <383CFF04.56BA9193@praxis.cz>
Message-ID: <383D5EA2.2988@hiwaay.net>

Matthew Gertner wrote:
> 
> > Cost justify XML.
> 
> This is interesting argument, but:
> 
> 1) It is far from clear that XML solutions will have to be sold for less
> because of "hyped perception of ease and ubiquity"

What we are seeing is a hype that XML has some magical effect on the 
bottom line, but the dirty secret is it costs as much or more, and just 
like SGML, if I need consultants and BizPartners just to implement it, 
it is a failed technology.  (Remember, this is just Us Chickens 
talking and exploring potentials; I can make a case for SGML/XML but 
that is coals to newcastle on this list.)

I admit the power of branding, but as more services 
come online to differentiate on price or any other characteristic 
which the customer uses (eg:  gotta have what kid says they gotta 
have), then buying customers with pricing is one way to increase 
the power of the branding.  What the Kroger experience showed 
was that the online model was not necessarily good for business 
even if it was good for the consumer.

XML won't be sold for less unless the TCO is less.  
There are still many markets where competition is based on barrier to
entry.   
Having the press screaming is a double edged sword.  It gets attention
but it 
raises expectation and in revolution counter-revolution cycles, 
not meeting expectations is like dating a runway model and failing 
to have cab fare on the first date.  My point is more that the 
platforms are unstable, XML can't fix that (SGMLers know the real 
misery of this because they don't blame the platform), and the 
folks who use XML need it hidden from them anyway.  

> 2) Do you really think that XML gives the same results as an RDBMS and
> CSV? 

Yes.  By the time any competent developer creates the function libraries 
for moving CSV around, they also develop the utilities to make it 
easy to do the necessary schema mapping.  That is actually the hardest 
part and fact is, its not that hard.  XML adds very little as a magic 
parse except in shrinking the number of parsers.   

> Just to give one example, if I have a PHP/ColdFusion/ASP/whatever
> site delivering HTML and I suddenly discover that I need to support WAP
> (or Ariba Network or PDF or...) I am forced to reimplement everything
> and then maintain my two (or three or four) versions in parallel. If I
> go for an XML-based solution, then much of my site logic can be drawn up
> out of the RDBMS into the XML layer, and the step to the various
> delivery formats is only a transformation away. Saving time means saving
> money, how's that for a cost justification?

Lousy.  The transform can be done at the server before that middle tier 
is ever called.  It is easy to do, done in the language the implementor 
is familiar with, requires little mapping to the tree, etc.  IOW, it is 
just an extra layer of work as far as the implementor sees it. 
Downtranslation 
is downtranslation.  When you are using recordsets, the structural 
model is already efficient, flat, and optimized.  Pushing XML or CSV 
out is about the same.  Where XML gets an edge is if the guy on the 
other end has only weakly agreed to names and membership.  BTW, most 
contracts already read "you will use our COTS schema".

> Nevertheless, there is a need for people to start implementing stuff and
> establishing a community where schemas, stylesheets and the like can be
> "discovered" rather than developed from scratch whenever needed.

Which is why ecom-ecologies emerge from contract negotiations.  It is 
not "discovery".  That is a rotten business model.  It is negotiation
and if 
the emerging registries such as OASIS or BizTalk are to thrive, it 
will be because they provide negotiation services for contracted 
performance.   Again, this isn't a catalog ordering site such as 
toysRUs but the full monty of big corporate projects with primes, subs, 
logistics orgs and all of that.  XML application languages are useful 
for this but only insofar as they provide predictable reliability 
figures (MTBF, MTTR, etc) and that is actually a component level 
statistic, not directly attributable to XML.

> We also
> need more and better tools, especially on the authoring side. The
> investment in getting an XML-based solution up and running is relatively
> high, and even the subsequent leverage that this provides will pay back
> this investment relatively quickly. There's a real risk that
> out-of-the-box solutions will appear that provide only a portion of the
> potential added value of XML but are so easy to implement and deploy
> that they edge more powerful approaches out of the market. Something to
> be scared about.

I think we will get all of that, but we are already seeing a crack the
whip 
dilemma in tools development.  That makes me more uneasy because unless 
I have component level statistics for reliability, I am back exactly
where 
I started:  pick one vendor and stick with them; justify XML by
lifecycle 
costs and avoid it for short lifecycle, non-aggregating information.

ln


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 16:28:00 1999
From: philipnye at freenet.co.uk (Philip Nye)
Date: Mon Jun  7 17:17:39 2004
Subject: URI's in namespaces
References: <000401bf36c9$844c1bd0$0f36a8c0@quokka.com> <383D59B9.EDF684D1@prescod.net>
Message-ID: <383D6353.25C8C0C4@freenet.co.uk>

Paul Prescod wrote:
> 
> "Jeffrey E. Sussna" wrote:
> > ... Why
> > not just make namespace targets ordinary XML names?
> 
...
> The reason we traditionally manage our URI namespace is because we want
> to manage the description of retrievable resources. Therefore, if we USE
> our pre-existing URI infrastructures then we will always come up with
> URIs that look suspiciously (and confusingly) like URLs. They will
> always be based on domain names and we know that domain names change
> hands.
> 
> If we DO NOT use these infrastructures, then we can come up with more
> persistent, less confusing namespaces, but then we've lost the whole
> benefit of using URIs! For instance, there is no reason that we should
> use http://www.w3.org/1999/XSL/Transform instead of the less confusing
> www.w3.org.1999.xsl.transform since neither one really follows the W3Cs
> website structure ANYHOW.

Further to this argument - managing URIs within a domain is largely self
enforcing when the URI resolves directly or indirectly to a concrete
resource - management is done implicitly. When the requirement is simply
to reserve a worldwide unique name, enforcing the mechanism is an
explicit management task - because of this the infrastructure may well
not exist at all and is certainly open to errors and abuses.

Philip Nye
--
Engineering Arts
72 Herberton Road  ~  Bournemouth  BH6 5HZ  ~  UK
tel +44 (0)1202 418236  ~  fax +44 (0)1202 418676
mailto:philipnye@freenet.co.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 17:12:21 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:39 2004
Subject: Handheld computers
Message-ID: <004601bf376b$bcb12ea0$42f96d8c@NT.JELLIFFE.COM.AU>


From: Matthew Gertner <matthew@praxis.cz>

>You forgot:
>
>4 - CDATA is redundant, entities are a less elegant solution to various
>problems that could be solved with XLink and/or schemas, processing
>instructions and comments would be better structured using normal
markup
>and notations are just weird mime types. These features increase
>complexity without adding significant value and only found their way
>into XML in the first place because certain vested interests wanted
them
>to ease the migration path from SGML to XML.

Vested interests?  Ah hear we go again: XML 1.0 as free-thinking XML
turks fighting the crusty old SGML guard.  The idea that easing the
migration path from "SGML" to "SGML-on-the-Web" is bad is laughable:
that is what XML was supposed to do honey!  That was its main job, not
some hijacking by moustachioed villians or over-protective priests.

CDATA is not redundant, becuase XML is a markup language: a markup
language has the definite requirement that it should have some features
to allow pre-existing test to be marked up easily.  The alternatives of
" and ' as attribute value delimiters are another example: as I
mentioned, they are no only useful for embedding markup but many other
kinds of computer text.  XHTML has
    <script><![CDATA[[
    ]]></script>
as a notable example.

As for XLink and Schemas (and XInclude aka SNIP), there will be no
guarantee that receiving software can process them either, so they
cannot be any more reliable than entities.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ht at cogsci.ed.ac.uk  Thu Nov 25 17:21:10 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:17:39 2004
Subject: Linking a XML document to its schema
In-Reply-To: John Aldridge's message of "Thu, 25 Nov 1999 13:23:26 +0000"
References: <f5bg0xuvoa7.fsf@cogsci.ed.ac.uk> <3.0.6.32.19991125132326.00c23d70@mailhost>
Message-ID: <f5bbt8isd1n.fsf@cogsci.ed.ac.uk>

[ web-proofing you instance->DTD connections, with an eye on schemas]

> (a) I'm an idiot, and I've missed some obvious solution to this problem.

You're not an idiot, but there is a partial solution which is better
than the one you've tried, namely, a relative URL, e.g.

   <!DOCTYPE Linestyle SYSTEM "MyApp.dtd">

then you've made minimal assumptions about the directory structure
on your clients.

We're certainly trying to improve the situation for use cases like
yours in XML Schema.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From martind at netfolder.com  Thu Nov 25 17:34:02 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:39 2004
Subject: URI's in namespaces
In-Reply-To: <383D6353.25C8C0C4@freenet.co.uk>
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEKHEHAA.martind@netfolder.com>

Hi,

Paul Prescod wrote:
>
> "Jeffrey E. Sussna" wrote:
> > ... Why
> > not just make namespace targets ordinary XML names?
>
...
> The reason we traditionally manage our URI namespace is because we want
> to manage the description of retrievable resources. Therefore, if we USE
> our pre-existing URI infrastructures then we will always come up with
> URIs that look suspiciously (and confusingly) like URLs. They will
> always be based on domain names and we know that domain names change
> hands.
>
> If we DO NOT use these infrastructures, then we can come up with more
> persistent, less confusing namespaces, but then we've lost the whole
> benefit of using URIs! For instance, there is no reason that we should
> use http://www.w3.org/1999/XSL/Transform instead of the less confusing
> www.w3.org.1999.xsl.transform since neither one really follows the W3Cs
> website structure ANYHOW.

Philip wrote:
>Further to this argument - managing URIs within a domain is largely self
>enforcing when the URI resolves directly or indirectly to a concrete
>resource - management is done implicitly. When the requirement is simply
>to reserve a worldwide unique name, enforcing the mechanism is an
>explicit management task - because of this the infrastructure may well
>not exist at all and is certainly open to errors and abuses.

Didier says:
So, in fact, the major problem is the usage of the <protocol> part of the
URL. It implicitly convey the information that the HTTP protocol will be use
to resolve this URL. If nothing is located at this URL the only information
returned through the HTTP protocol is an HTTP error. However, if you resolve
the following URL:  http://www.w3.org/1999/XSL/Transform here is what you
get:

<W3C logo here>
This is an XML namespace defined in the XSL Transformations (XSLT) Version
1.0 specification.

See also:

The Extensible Markup Language (XML) 1.0
Namespaces in XML

----------------------------------------------------------------------------
----

Webmaster

So, in the case of W3C the xsl name space URI points to a document. This
document contains several links:
a) a link to the xsl recommendation which further define the xsl name space
b) a link to the XML 1.0 recommendation
c) a link to the name space recommendation

If all name space URIs would point to as much info as this, this would be
marvelous. I guess that the next step would be to have a recommendation as
to what kind of document is found at the other end of a name space URI. For
example an XML document which would include links to information sufficient
to understand this name space
a) Document for both human consumption and machine consumption
b) links to recommendations on which this name space is built

Hummm, this start to resemble a _real_ semantic Web ;-)

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From matthew at praxis.cz  Thu Nov 25 17:41:21 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:40 2004
Subject: Handheld computers
References: <004601bf376b$bcb12ea0$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <383D749E.C9A3D893@praxis.cz>

Rick Jelliffe wrote:
> Vested interests?  Ah hear we go again: XML 1.0 as free-thinking XML
> turks fighting the crusty old SGML guard.  The idea that easing the
> migration path from "SGML" to "SGML-on-the-Web" is bad is laughable:
> that is what XML was supposed to do honey!  That was its main job, not
> some hijacking by moustachioed villians or over-protective priests.

Okay, maybe I went a little overboard with that vested interest
business. Paul made exactly the same point. On the other hand, I get
called honey even less often than I get called reasonable, so perhaps
the hyperbole can be justified. :-)

Quite seriously, it is a simple fact that many of the features that
found their way into XML are becoming increasingly redundant as various
auxiliary standards mature. When the dust has settled on the schema and
linking efforts (whether in 3, 6 or 12 months time), wouldn't it make
sense to look at features such as entities and notations with a critical
eye and decide whether they are still adding more value than they cost
in complexity (and subsequent barriers to understanding and implementing
XML). My very personal opinion is that the argument for SML based on
targetting devices with limited memory and computational power is bogus.
However, XLink, XPath, XML Schema, namespaces and all the rest are
expanding the scope, and thus the complexity, of XML everyday. If there
isn't some corresponding impetus for simplication in other areas then we
will indeed run up against a wall eventually. This may be inevitable,
but by taking the issue seriously now we can at least hope that it will
be later rather than sooner.

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.aldridge at informatix.co.uk  Thu Nov 25 18:13:25 1999
From: john.aldridge at informatix.co.uk (John Aldridge)
Date: Mon Jun  7 17:17:40 2004
Subject: Linking a XML document to its schema
In-Reply-To: <f5bbt8isd1n.fsf@cogsci.ed.ac.uk>
References: <John Aldridge's message of "Thu, 25 Nov 1999 13:23:26 +0000">
 <f5bg0xuvoa7.fsf@cogsci.ed.ac.uk>
 <3.0.6.32.19991125132326.00c23d70@mailhost>
Message-ID: <3.0.6.32.19991125181250.00bb5db0@mailhost>

At 17:20 25/11/99 +0000, you wrote:
>>[ web-proofing you instance->DTD connections, with an eye on schemas]
>
>You're not an idiot, but there is a partial solution which is better
>than the one you've tried, namely, a relative URL, e.g.
>
>   <!DOCTYPE Linestyle SYSTEM "MyApp.dtd">
>
>then you've made minimal assumptions about the directory structure
>on your clients.

I guess this would be workable in a tightly constrained system which
guaranteed that the XML files would only ever be written to one (or a few)
locations.

In our case, though, the location is under customer control (via a
"File->Save As..." command, or similar), and I don't think it'd be
acceptable to tell our customers that they must copy the DTD to any
directory in which they ever save an XML file.

>We're certainly trying to improve the situation for use cases like
>yours in XML Schema.

That's good news.  Does "XML Schema Composition Task Force Report: Partial
draft (1.2)" describe the most recent published thinking on this subject?
I'll go away and read it.

Thanks for your help.
-- 
Cheers,
John

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 18:24:11 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:40 2004
Subject: Handheld computers
Message-ID: <00a601bf3775$c2de8ed0$42f96d8c@NT.JELLIFFE.COM.AU>

 From: Matthew Gertner <matthew@praxis.cz>

>My very personal opinion is that the argument for SML based on
>targetting devices with limited memory and computational power is
bogus.

My first 2.5 years programming was on assembler for real-time
controllers,
it could take 3 months to write a program and then 3 months to figure
out
how to make it fit into the PROM.  So I certainly have sympathy for the
view
that small is beautiful: but how does a device that has such small
memory
requirements fit in networking capability anyway?  And if it is not a
Web
device, why is the topic raised on XML-DEV and not comp.text?

>However, XLink, XPath, XML Schema, namespaces and all the rest are
>expanding the scope, and thus the complexity, of XML everyday. If there
>isn't some corresponding impetus for simplication in other areas then
we
>will indeed run up against a wall eventually. This may be inevitable,
>but by taking the issue seriously now we can at least hope that it will
>be later rather than sooner.

I expect there will be a successor to XML one day. And ISO 8879 will
undoubtedly have a maintainence fix so that it too is SGML.

But if you want simplification, the worst thing you could do at the
moment
is push either an XML++ or an XML--

That would not result in any simplification of our lives at all: it
would
just provide a mechanism for the company men to adopt whichever
markup language will cause their competitors most harm. This is
rational behaviour, and we should expect it.

TCP/IP is incredibly complicated, and who cares?  The IP NG people have
rhetoric about it (they need to justify their research efforts) but it
is
working spectacularly well.  We only care about the layer we deal with,
after things are set up.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 19:33:07 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:40 2004
Subject: About XML document linkage and Schemas.
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90A5@sohos002.ied-support.net>

Didier PH Martin wrote:
> And in the same vein: how do we link a document to its meta data?

Since you can never know all the occurrences of the meta data for a
document, I would have thought this is impossible. Of course you could
link to the meta data you happen to know about, but then it gives the
appearance of completeness when there is none. Shouldn't you just link
the meta data to the document, for which RDF is very suitable?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 19:33:04 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:40 2004
Subject: What is a document?
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90A4@sohos002.ied-support.net>

Don Park wrote:
> Mark Birbeck replied:
> >Not true - XML Fragment Interchange suggests a simple way to 
> >do all that you say.
> 
> Mark, I think you misinterpreted the XML Fragment Interchange spec.
> It suggest a way to provide context information about a fragment
> of an existing document.

No - I didn't misunderstand the spec. Your first message said:

> By its nature, a fragment is likely to be missing some
> information (parameters if you will) that must be provided
> by the context.  We currently have no mechanism to do
> this but we will need it eventually.

and I believe that what you said *is* addressed by the FI spec.

However, in your follow up you indicate that you meant something
different from that initial message. You wrote:

>  I was talking about some means to specify and constrain
> where a standalone fragment (meaning that it is not a
> complete document and is also not part of another document)
> may be used and what context information is needed to use it.

This is different. Surely a fragment's applicability or otherwise comes
from the schema of the containing document, not the fragment itself?
Have you some scenarios in mind where the fragment should limit where it
can appear, rather than a schema or DTD doing that job?

Anyway, here are a few notes to illustrate the use of fragments. With
this in my database:

	<nitf ID="1">
		<body>
			<body.head>
				<hedline>
					<hl2>The headline</hl2>
				</hedline>
			</body.head>
		</body>
	</nitf>

I have a system where this URL:

	http://xyz/articles/nitf[ID=1]/body/body.head/hedline/hl2

returns simply:

	<hl2>The headline</hl2>

More fun is that before I send out the resulting XML I have a quick look
for rdf:resource attributes, so this, in the database:

	<rdf:Description about="http://xyz/articles/nitf[ID=1]">
		<dc:Creator resource="http://xyz/people/x:person[ID=1]"
/>
	</rdf:Description>

will become this (namespace declarations are present, just excluded
here) on delivery:

  <rdf:Description rdf:about="http://xyz/articles/nitf[ID=1]">
    <dc:Creator>
      <x:person ID="1">
        <vcf:vCard>
          <vcf:n>
            <vcf:fn>Mark Birbeck</vcf:fn>
          </vcf:n>
          <vcf:photo>
            <vcf:extref vcf:uri="http://library/MB.jpg" />
          </vcf:photo>
        </vcf:vCard>
      <x:person>
    </dc:Creator>
  </rdf:Description>

Now, whether the vCard/x:person fragment can appear as a child of
dc:Creator is up to the container definitions, not up to vCard. (I'm
being loose with my interpretation of dc:Creator during the development
of this system, but ignore that!) In this case vCard *can* be a child of
x:person, and a grandchild of dc:Creator, since the relationships are
RDF statements, not ordinary XML.

All I'm asking then, is, what situations do you see in which the
fragment itself - say the vCard or x:person in my scenario - must
indicate where it can and cannot appear? I think that to do that would
be a major change from the approach that DTDs and XML normally works
(defining the valid children, not the valid parents). The examples I've
given above show how fragments of other XML documents can be
incorporated within an XML document, and how XPath can be used a syntax
that allows you to specify that.

Best regards,

Mark

Mark Birbeck
Managing Director
x-port.net Ltd.
220 Bon March? Centre
241-251 Ferndale Road
London
SW9 8BJ
w: http://www.iedigital.net/
t: +44 (171) 501 9502
e: Mark.Birbeck@iedigital.net

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 20:21:42 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:40 2004
Subject: XML:  Still Just HypedWebStuff
In-Reply-To: Len Bullard's message of "Thu, 25 Nov 1999 10:06:58 -0600"
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain> <383C1863.6CE3@hiwaay.net> <383CFF04.56BA9193@praxis.cz> <383D5EA2.2988@hiwaay.net>
Message-ID: <m3vh6qqq62.fsf@localhost.localdomain>

Len Bullard <cbullard@hiwaay.net> writes:

> What we are seeing is a hype that XML has some magical effect on the 
> bottom line, but the dirty secret is it costs as much or more, and just 
> like SGML, if I need consultants and BizPartners just to implement it, 
> it is a failed technology.

Both statements are false: SGML and XML don't do much, and they don't
cost much.

High-volume custom publishing systems, complex interactive databases,
document management systems with word-level granularity, large
customizable dynamically-constructed Web sites, and other such goodies
*do* cost a lot, and they'd cost a lot with or without SGML or XML
(you probably save a trivial amount because you can use OTS software
for a few of the tasks).

That's not a bad thing, as long as people are building those systems
for the right reasons (they need them) and not for the wrong reasons
(they think that something about SGML or XML compells them to).

I'm really, really tired of people writing that XML is expensive.
That's like saying that tires are expensive because you have to buy a
Jaguar to put on top of them.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Thu Nov 25 21:12:10 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:40 2004
Subject: About XML document linkage and Schemas.
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90A5@sohos002.ied-support.net>
Message-ID: <NBBBJPGDLPIHJGEHAKBAAEKKEHAA.martind@netfolder.com>

Hi Mark,

Mark said:
Since you can never know all the occurrences of the meta data for a
document, I would have thought this is impossible. Of course you could
link to the meta data you happen to know about, but then it gives the
appearance of completeness when there is none. Shouldn't you just link
the meta data to the document, for which RDF is very suitable?

Didier reply:
Of course you cannot know in advance all the possible meta data about an XML
document. But let's say that you want to provide a limited set for an
context like, for instance, e-commerce. And if we think a bit more about the
meta data topic, what we want, most of the time, is not the whole set but
more what is pertinent to the context.

Use case:
You have an invoice formatted as an XML document to send to a business
partner. Some choices are given to you:
a) use the biztalk framework and then have the biztalk framework provide
some meta data for your document and your document being transformed into a
biztalk document fragment.
b) use another mechanism where you document is the document and 1) has,
associated to it, a certain meta data set packaged in a separate document
(i.e. href) or b) includes the limited meta data set.
c) other options...

To rely on a) means that Microsoft decides on what to include in this
limited set of meta data such as:
a) to whom or what is this document targeted
b) from whom or what this document is coming from
c) For which purpose this document is used for
etc...

The good point is that the meta data set is defined, the bad point is that a
monopoly controls this set :-)

If, however, there is a standard way to refer to or include a set of meta
data particular to a certain XML document, then, a monopoly is not at the
hart of the decision process on how you format your document (transformed
into a document fragment).

So, for instance, if we where able to do:

<myInvoice xmlns="http://www.xml.org/Myinvoice">  <------ and that this URI
would point to a page containing links about this name space as found
actually in W3C site for their own name spaces.
..... some content here......
<rdf:RDF xmlns="....."> again same thing as above
... all the limited meta data set here.....
</rdf:RDF>
... other content here....
</MyInvoice>

So here what is received by the trading partner is a "myInvoice" document
type or more particularly a "MyInvoice" name space or vocabulary defined
somewhere by a) a schema, b) a human readable document explaining the
schema. Most preferably the document at the other end of the URI would be an
XML document able to contain more than just the schema.

The good thing is that now your document is not longer a fragment in a
document controled by a monopoly but a document that you and your business
partners agreed on. The bad thing is that you do not have a monopoly to
organize your life :-). No seriously, you would have to define with your
business partners the limited meta data set required for a transaction
context.

So, On one hand, there is a way to convey limited meta information set. It
is to create a new document type, name space or vocabulary as actually done
with the biztalk framework. In this last case, the "MyInvoice" name space is
included in the main biztalk document as a fragment. Thus, the biztalk
document has been created mainly to convey a limited meta data set and the
mechanism used to convey the document and its meta data is to transform the
original document into a fragment and embed or include this fragment in the
meta data vehicle, which by the way became the main document. what is
driving the cow? the tail or the head?.
On the other hand, your document could stay as a document but any meta data
set being included as a fragment (or linked to an external meta data
document).

So, the real issue about the whole biztalk affair or nay biztalk like kind
of framework is what is driving the cow? the tail or the head? or said more
formally ;-) do we embed the document into the meta data and transform the
document into the meta data document as a fragment or do we, instead,
include meta data as a fragment in the document. the tail? the head? which
one? :-))

My concern or focus is: Is there a standard way to include a limited meta
data set in a document. Actually, it seems that yes I can embed a RDF
fragment to do so. However, there is no standard way to refer to an external
meta data document (i.e. having an hRef to the rdf document or an href to a
collection of rdf documents). So the document may embed a rdf fragment in a
standard way using the rdf recommendation but there is not standard way to
have a document refer to its related meta data (as I said, a limited set
pertinent to the context).

Note that this last feature is very important. Lets say now ,that I send to
you a document about XML. This latter could be created dynamically by a tool
which will not only send to you the document but also a collection of meta
information about the XML subject. The meta data collection could be other
related topics and thus could use something like topic maps links,
information on who created the document etc... The browser can then show you
what's related to this document. To do so, we need a standard mechanism to
point, from an XML document to a limited meta data set. I said limited
throughout this message because, as you said, we won't provide the whole set
of meta data about a document but always a limited set. The set of meta data
that we own, are aware of or simply can provide or even more pertinent, the
meta data related to the context.

Thus, we can now envision that an XML document is not an island but a
document that _could_ have:
a) a link or that it embeds a style sheet for rendition
b) a link or that it embeds a limited set of meta data bout this document
c) a link or that it embeds other kind of meta data like information about
its structure and what is valid (different from (b) which provide more
contextual or semantic information about the content than about the form or
the structure)
d) Obviously, the document content itself can contain links to other
documents

To better imagine that an XML document could contain a limited meta data set
it suffice to imagine that the XML document is not a simple file resident on
a system and simply accessed with a file system like HTTP GET but more like
a dynamic document created and that the user agent may require to:
a) get all the information (i.e. the document itself and related
information - this through a standardized links or standard fragments
b) get only the document without any related information
c) get only a fraction of the related information.

Hope I gave a better view of my XML world view and what are partially the
rationales behind what I said.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 22:40:26 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:40 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAOEJOEHAA.martind@netfolder.com>
Message-ID: <000701bf3796$655737a0$099918d1@docuverse1>

>This has the merit to be simple, easy to use and remember and 
>most of all - it has a coherent rule.

Cool.

>I added the "/" at the end of the element. Is it like that in 
>SML when you have a singleton element?

You mean empty element.  Yes.  Empty element short-hand is
used commonly so it makes sense to support 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 23:28:07 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:40 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90A4@sohos002.ied-support.net>
Message-ID: <000801bf379d$0f5b5460$099918d1@docuverse1>


Mark,

You quoted me out of context.  The paragraph you quoted was a
reply to the following paragraph which clearly points out that
the context of the discussion was the need for a fragment to
impose constraint on its container:

Written by somebody, I forget who (sorry):
>I wouldn't impose such a limitation myself. Why should the fragment
>'know' anything about its container? (If I understand you correctly -
>and apologies if I don't.) Provided it has its namespace declaration
>then it can in theory exist in any container that will have it.

Mark Birbeck wrote:
>This is different. Surely a fragment's applicability or otherwise comes
>from the schema of the containing document, not the fragment itself?
>Have you some scenarios in mind where the fragment should
>limit where it can appear, rather than a schema or DTD doing that job?

Imagine a repository of XSLT templates which is used by XSL editors
to construct a XSLT document in a top-down fashion.  Select an element
in the source tree and you will see a list of templates that can be
applied.  Most likely not all templates will be appropriate for
insertion.  Note that each XSLT templates are, in fact, XML fragments.
This is an example of constraints an XML fragment might impose on its
container.

Another example is an e-wallet which holds private information.  When
a service requires some bits of information and the owner of the wallet
approves, wallet sends the information in XML.  Requesting service
defines the format it wants dynamically using a format similar to a
form and the wallet injects necessary information as if it was filling
out the form.  If a wire-transfer directions must be sent, it can not
be just dropped into any location in the outgoing message.  While this
problem can be solved in other ways, suppose I find it ideal to have
this 'constraint' encoded into each item in the wallet for
extensibility.  Again, this is an example of constraints an XML fragment
might impose on its container.

Are we in sync?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 25 23:43:10 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:40 2004
Subject: Linking a XML document to its schema
In-Reply-To: <NCBBIPMOPKLLGKJPBINCKENBDFAA.reschke@medicaldataservice.de>
Message-ID: <000901bf379f$2747ae00$099918d1@docuverse1>

>So it seems it is best to have one XML schema reference per 
>namespace that is in use in the document, right? My impression
>was that this wouldn't work with the proposal you made...

I am afraid you misunderstood.  Try working it out with an
example composite XML document.  Note that validation requires
a validating mechanism that uses 'triggering' information from
within the document or its context (MIME type, file extension,
etc).  Which information serves as the trigger is arbituary and
is subject to standardization efforts.  XML Namespace is an
option but it has drawbacks such as many-to-many relationships
between namespace and schemas.  There are other options.

>Maybe I have misunderstood something...

It happens to the best of us.  Luckily, I am not the best.  <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Thu Nov 25 23:53:42 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:40 2004
Subject: About XML document linkage and Schemas.
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90A6@sohos002.ied-support.net>

Hello Didier,

Heads or tails?

I have been concerned with exactly this issue recently, and I have
concluded the opposite to you! I wonder if part of the issue relates to
an interpretation of RDF.

RDF and Dublin Core (DC) have been closely associated, however they deal
with very different things:

- DC specifies a common series of tags that might apply to
  a wide range of resources - articles, songs, books, email.
- RDF relates to the specification of statements about
  resources

I mention this partly because of your statement:

> Actually, it seems that yes I can embed a RDF
> fragment to do so.

IMO it is not really right to embed RDF within something. I know people
often embed DC and that's why I'm drawing the distinction:

	<x:article ID="1">
		<dc:title>Cows: Which way up?</dc:title>
		<dc:Creator>Didier PH Martin<cd:Creator>
		<x:subtitle>
			In-depth examination of whether a cow
			is controlled by its head or tail
		</x:subtitle>
		<x:text>
			<x:p>Cows are interesting beasts</x:p>
		</x:text>
	</x:article>

This seems just about alright to me, but probably about as far as you
should go with meta data. (You'll see later that I wouldn't even make
the author a property of an article.) Anything more - keywords,
categories and so on - should be elsewhere. For example:

On my server:

	<rdf:Description about="http://didierserver/article[@ID=1]">
		<dc:subject>Cows, heads, tails</dc:subject>
	</rdf:Description>

and on the server storing classic works in the English language:

	<rdf:Description about="http://didierserver/article[@ID=1]">
		<dc:subject>Bovine</dc:subject>
		<x:rating>Brilliant</x:rating>
	</rdf:Description>

and on the server storing collected works of leading authors:

	<rdf:Description about="http://Didier Himself/">
		<vcf:vCard><vcf:n><vcf:fn>Didier PH
Martin</vcf:fn></vcf:n></vcf:vCard>
		<x:wrote>
			<rdf:Bag>
				<rdf:li
resource="http://didierserver/article[@ID=1]" /
				<rdf:li
resource="http://didierserver/poem[@ID=7]" /
				<rdf:li
resource="http://otherserver/song[@ID=6]" /
			<rdf:Bag>
		</x:wrote>
	</rdf:Description>

I have just implemented this very scenario on a server for publications.
I have used XMLNews-Story to describe the articles themselves. That
gives me the text of the article, its title and a few bits and bobs
about people, countries and so on in the article. Then I use RDF to
refer to this article and in one description I put the author, some
keywords and so on. But the interesting thing is that you can then make
further statements about that meta information. For example, to group
all articles on the same topic - say your article and poem about cows,
and my drawing of one - I can do this:

	<rdf:Description about="http://myserver/subjects/cows">
		<x:related>
			<rdf:Bag>
				<rdf:li
resource="http://didierserver/article[@ID=1]" /
				<rdf:li
resource="http://didierserver/poem[@ID=7]" /
				<rdf:li
resource="http://myserver/picture[@ID=20]" /
			<rdf:Bag>
		</x:related>
	</rdf:Description>

In my system the basic unit is no longer the web page, because my web
pages are made up from the following RDF statements:

  <rdf:Description ID="x">
    <rdf:Bag>
      <rdf:li
       ID="rdf:_1"
       rdf:resource="/article[@ID=3]"
      />
      <rdf:li
       ID="rdf:_2"
       rdf:resource="/meta/article[@ID=3]"
      />
    </rdf:Bag>
  </rdf:Description>

The resulting XML from this - resources get pulled in before the
complete XML is emitted - then gets transformed to HTML. This seems more
logical to me, since the HTML page is only one possible manifestation of
that article.

It raises an interesting problem for indexing and other software,
because it means that the meta information is information about the
article, not the web page. So if you use meta tags like dc:Creator, that
is for the XMLNews-Story article, not the web page since the web page
was 'created' by a machine on the fly. Currently much of what we do is
oriented towards web pages - but actually they are increasingly becoming
a means of viewing something else. In my case I would want an index
server to index my RDF meta documents, not my HTML output.

So, enough of my system - you asked about yours. How does what I have
said relate to it?

You suggest:

> <myInvoice xmlns="http://www.xml.org/Myinvoice">  <------ and 
> that this URI
> would point to a page containing links about this name space as found
> actually in W3C site for their own name spaces.
> ..... some content here......
> <rdf:RDF xmlns="....."> again same thing as above
> ... all the limited meta data set here.....
> </rdf:RDF>
> ... other content here....
> </MyInvoice>

I would suggest that this is not right. For a start you have to define
the schema for myInvoice to be able to contain meta information about
itself (unless you hold with this non-validation stuff that's doing the
rounds, in which case you can have a fish inside your invoice if you
want). But then it's no longer meta information if it's contained in the
invoice. But if you want to say something *about* invoices, then you
shouldn't have to modify the invoice schema.

This is why I said in my previous email that you can't know all
occurrences of meta information about your resource. I believe the
semantic web requires us to allow our resources to go off and have a
life of their own. Like our children we look on them affectionately and
look after them but we can't say who their friends are. (See how Didier
brings out the metaphor again!) For example, say your invoice is part of
a legal dispute - is that a property of the invoice (in which case you
add another element or possible value for an attribute) or is that a
statement *about* the invoice (in which case you use RDF)?

I would therefore suggest you turn the cow inside out:

	<rdf:RDF>
		<rdf:Description about="#1">
			... meta data ...
		</rdf:Description>
		<myInvoice xmlns="...">
			... invoice ...
		</myInvoice>
	</rdf:RDF>

is a completely open and flexible solution. Whether you then use BizTalk
to transport that is up to whatever situation you're in.

To answer you specifically:

> formally ;-) do we embed the document into the meta data and 
> transform the document into the meta data document as a
> fragment or do we, instead, include meta data as a fragment
> in the document. the tail? the head? which one? :-))

I think we embed the data in a document that includes the meta data, and
then embed *that* in the BizTalk transport mechanism (or SOAP, or
whatever you need for a particular job).

Then we turn the cow inside out and have some barbecued ribs.

Best regards,

Mark

Mark Birbeck
Managing Director
x-port.net Ltd.
220 Bon March? Centre
241-251 Ferndale Road
London
SW9 8BJ
w: http://www.iedigital.net/
t: +44 (171) 501 9502
e: Mark.Birbeck@iedigital.net

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 00:19:29 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:40 2004
Subject: What is a document?
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90A8@sohos002.ied-support.net>

Don Park wrote
> You quoted me out of context.  The paragraph you quoted was a
> reply to the following paragraph which clearly points out that
> the context of the discussion was the need for a fragment to
> impose constraint on its container:

I suspected as much - that's why I also asked the question which you
answer below.

> Written by somebody, I forget who (sorry):
> >I wouldn't impose such a limitation myself. Why should the fragment
> >'know' anything about its container? (If I understand you correctly -
> >and apologies if I don't.) Provided it has its namespace declaration
> >then it can in theory exist in any container that will have it.

That was me.

> Imagine a repository of XSLT templates which is used by XSL editors
> to construct a XSLT document in a top-down fashion.  Select an element
> in the source tree and you will see a list of templates that can be
> applied.  Most likely not all templates will be appropriate for
> insertion.  Note that each XSLT templates are, in fact, XML fragments.
> This is an example of constraints an XML fragment might impose on its
> container.
> 
> Another example is an e-wallet which holds private information.  When
> a service requires some bits of information and the owner of 
> the wallet
> approves, wallet sends the information in XML.  Requesting service
> defines the format it wants dynamically using a format similar to a
> form and the wallet injects necessary information as if it was filling
> out the form.  If a wire-transfer directions must be sent, it can not
> be just dropped into any location in the outgoing message.  While this
> problem can be solved in other ways, suppose I find it ideal to have
> this 'constraint' encoded into each item in the wallet for
> extensibility.  Again, this is an example of constraints an 
> XML fragment
> might impose on its container.
> 
> Are we in sync?

Yes.

I think both of these are very good examples, but I think that the
information you desire could not be in the fragment itself. The reason I
used the example of returning one node in my previous message was
because it raises the question "where would you put these restrictions?"
I think both of your examples are application specific, and so would
require a specific solution. The discussion about fragments and so on is
a general solution that could be applied across all XML.

(As it happens I think you could do the XSL editor one with a dynamic
schema that your editor understood. As you edit the document and add
nodes you can modify the schema. As you get to each node you can present
a list of valid children - from the schema.)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 00:52:02 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:40 2004
Subject: What is a document?
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90A8@sohos002.ied-support.net>
Message-ID: <000001bf37a8$c5c7c3e0$099918d1@docuverse1>

>> Written by somebody, I forget who (sorry):
[snip]
>That was me.

OOPS!:)

>I think both of these are very good examples, but I think that the
>information you desire could not be in the fragment itself. 
>The reason I used the example of returning one node in my
>previous message was because it raises the question "where
>would you put these restrictions?"

While some of the information could be part of the fragment,
encoded in an out-of-band namespace of sort, I think you are
right that remaining information will have to be stored
externally.  At this point, I am thinking that a sort of
'connection' or 'glue' fragment which 'includes' the target
fragment could be used.  This 'glue' fragment could be treated
exactly like the original and is an excellent place to fill-in,
override, translate some of the missing pieces in the target
fragment.  Like putting blue rubber coating over wire to indicate
its capability and than putting it a bin that provides its
purpose...  Hmm, that analogy was lacking something...

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 00:59:26 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:40 2004
Subject: Handheld computers
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90A9@sohos002.ied-support.net>

Rick Jelliffe wrote:
> My first 2.5 years programming was on assembler for real-time
> controllers,
> it could take 3 months to write a program and then 3 months to figure
> out
> how to make it fit into the PROM.

Wow ... never thought I'd see that word again!


You got out after 2.5 years! You lucky ...


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 01:56:11 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:41 2004
Subject: What is behind IE v 5.0 ?
Message-ID: <009701bf37b1$a117e4e0$5df5c13f@PaulTchistopolskii>



Hello. 

When playing with some xml files, 
( there is nothing about dsssl in my .xml 
files even there is no word dsssl - I don't know 
why IE decided that there is *anything* related to 
dsssl in my .xml file). I got IE v 5.0  to display the 
following stuff:

-------------------------------------        IE 5.0 displays:

The XML page cannot be displayed 
Cannot view XML input using XSL style sheet. 
Please correct the error and then click the Refresh button, 
or try again later. 

--------------------------------------------------------------------------------

Required white space was missing. Line 126, Position 42 

<ul type="[xxxdsssl:E: cannot open "services_result.dsl" (No such file or directory)
-----------------------------------------^

Again - 
ul type="[xxxdsssl 

is *not* from my document.

There is type="[xxx]"  instead.

Also I found nothing about DSSSL in 'About' 
dialog box, which reffers to some other 
non-MS stuff used in MS.

Comments are welcome  ;-)

Rgds.Paul.




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



From martind at netfolder.com  Fri Nov 26 02:22:58 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:41 2004
Subject: What is behind IE v 5.0 ?
In-Reply-To: <009701bf37b1$a117e4e0$5df5c13f@PaulTchistopolskii>
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEKPEHAA.martind@netfolder.com>

Hi Paul,

Unfortunately I cannot comment on this but find the phenomenon interesting
Maybe somebody used some needle in style sheets and invoked the vaudoo. :-)

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
Paul Tchistopolskii
Sent: Thursday, November 25, 1999 8:58 PM
To: xml-dev@ic.ac.uk
Subject: What is behind IE v 5.0 ?




Hello.

When playing with some xml files,
( there is nothing about dsssl in my .xml
files even there is no word dsssl - I don't know
why IE decided that there is *anything* related to
dsssl in my .xml file). I got IE v 5.0  to display the
following stuff:

-------------------------------------        IE 5.0 displays:

The XML page cannot be displayed
Cannot view XML input using XSL style sheet.
Please correct the error and then click the Refresh button,
or try again later.

----------------------------------------------------------------------------
----

Required white space was missing. Line 126, Position 42

<ul type="[xxxdsssl:E: cannot open "services_result.dsl" (No such file or
directory)
-----------------------------------------^

Again -
ul type="[xxxdsssl

is *not* from my document.

There is type="[xxx]"  instead.

Also I found nothing about DSSSL in 'About'
dialog box, which reffers to some other
non-MS stuff used in MS.

Comments are welcome  ;-)

Rgds.Paul.




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



From jelks at jelks.nu  Fri Nov 26 04:33:30 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:41 2004
Subject: New XHTML WD
In-Reply-To: <Pine.LNX.4.10.9911212204510.5424-100000@cauchy.clarkevans.com>
Message-ID: <NBBBICMNIPCICMKJECCBAEFPDCAA.jelks@jelks.nu>

There is a new Working Draft for XHTML at:

	http://www.w3.org/TR/xhtml1/

It requires the one namespace of http://www.w3.org/1999/xhtml to be used with
the three different document types.


/Jelks


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 05:09:57 1999
From: distobj at acm.org (Mark Baker)
Date: Mon Jun  7 17:17:41 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <383CF678.F0FB16B1@prescod.net>
References: <"199911232329888.SM01008"@Unknown>
Message-ID: <3.0.2.32.19991126000518.01029584@pop1.sympatico.ca>

At 09:42 AM 11/25/99 +0100, Paul Prescod wrote:
>Cell phones must increasingly deal with structured information.
>Therefore cell phones need to deal with XML.

Agreed, but that doesn't answer the question of "Why XML?".  Why not ASN.1,
SGML, SML, or a non-standard binary encoded XML that might be more suitable
over small pipes?  The proxy on the last-hop to the cell phone can take
care of bidirectional conversion, right?

IMHO, that answer only arrives once you realize that this structured
information isn't restricted to travelling the client/server path and
always going through that proxy.  What if I want to send a web page or
vCard or whatever to another cell phone via IR or Bluetooth, where there's
no proxy available?  That's where a well-deployed standard matters, and
*that's* "Why XML?".

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Fri Nov 26 05:13:00 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:41 2004
Subject: facts, conclusions, and exhortations re XML (long)
In-Reply-To: <Pine.LNX.4.10.9911212204510.5424-100000@cauchy.clarkevans.com>
Message-ID: <NBBBICMNIPCICMKJECCBKEFPDCAA.jelks@jelks.nu>

Clark C. Evans wrote:

> Surely Microsoft (the well-funded pre-release alpha software giant) has:
>
> 1. Announced (several months in advance) about their upcoming Explorer,
>    detailing how it will closely follow the W3C's recommendatoins.

AFAIK there has been no public announcement of the availability of the next
version of IE.  They just released IE 5.01, which has some bug fixes, most
notably that general entities are now displayed when a CSS stylesheet is applied
(before, with IE 5.0, such entities were "invisible" :).

Microsoft has committed to supporting XPath and XSLT.  See:

	http://www.w3.org/1999/11/xslt-xpath-test#Microsoft

Of course, they also said when HTML 4.0 was released that "Microsoft fully
supports HTML 4.0", yet you couldn't find a valid page on their entire site
(Marketing droids.  Depends on what the meaning of "fully supports" is...).
We'll see.  I'll venture that they will match their deeds to their words this
time around.  The focus is different, and they did, after all, participate
significantly in the development XSLT/XPath.

As to *when*, that's a million dollar question.  There are lots of other
factors: XHTML 1.x, schemas, XLink, etc., that are all fast moving targets.  And
there's the roll-out of Windows 2000 in February.

Next year is going to make for, well, an interesting landscape: IE 5.5 (or 6, or
whatever), Netscape 5.0, and Opera 4.0.

/Jelks


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



From support at bigriverinfotech.com  Fri Nov 26 06:49:40 1999
From: support at bigriverinfotech.com (Raymond)
Date: Mon Jun  7 17:17:41 2004
Subject: File Format Conversion Tools?
Message-ID: <383E2B20.6B8C239E@bigriverinfotech.com>

Could someone recommend tools to convert Office 97 documents ( word ,
excel , powerpoint ) to XML utilizing tags typically associated with a
"default" document, that is, information located in the file |
properties section of the associated application.

I am unsure if this is the proper forum for this inquiry.  If not please
direct me to the correct site(s).

Thanks in advance.

Raymond


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



From mikew at o3.co.uk  Fri Nov 26 07:45:18 1999
From: mikew at o3.co.uk (Mike Williams)
Date: Mon Jun  7 17:17:41 2004
Subject: XML Application Servers
In-Reply-To: Matthew Gertner's message of "Thu, 25 Nov 1999 10:25:08 +0100"
References: <383D0074.24083D68@praxis.cz>
Message-ID: <m3so1tzohs.fsf@picasso.o3.co.uk>

  >>> On Thu, 25 Nov 1999 10:25:08 +0100,
  >>> "Matthew" == Matthew Gertner <matthew@praxis.cz> wrote:

  Matthew> A question: who out there is developing applications delivering
  Matthew> XML from a server platform? How are you doing it?

I'm using XML as part of a Java servlet-driven framework.  The servlets
implement the control logic, and interact with EJBs which implement
business logic and DB access.  

The servlet collects output data in a hash-table.  Then, I (plan to) run a
template-processor, which splices this data into existing XML templates,
constructing an abstract view of the page. The templating system here is
similar to HTML templating systems like FreeMarker and WebMacro.  Templates
don't contain logic, just layout.

Finally XSLT transformtion into HTML, rather than delivering XML to the
client.

Has anyone done something similar?

-- 
Mike Williams

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 08:14:07 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:41 2004
Subject: [SML] Preliminary EBNF for SML
Message-ID: <000001bf37e6$897c6560$099918d1@docuverse1>

This message is for those interested in SML.  I would like
to suggest that we use the [SML] prefix to identify our
messages for filtering purpose.

Below is a preliminary version of EBNF for SML.  I would
appreciate your comments on it.  Notable changes are:

1. Limited name characters
2. Removal of 'gt' and 'apos'
3. Removal of ' as attribute value delimiter

#1 and #2 should be fairly controversial so I wanted to
get your feedback.  I do realize that, removal of 'gt' and
'apos' do not have any real benefits others except that
they are unnecessary.

data ::= (element | CharData | CharCode)*
element ::= StartTag data EndTag | EmptyTag
StartTag ::= ?<? Name (S Attribute)* S? ?>?
EndTag ::= ?</? Name S? ?>?
EmptyTag ::= ?<? Name (S Attribute)* S? ?/>?
Attribute ::= Name S? ?=? S? ??? ([^<&?] | CharCode)* ???
Name ::= NameStart (NameChar)*
NameStart ::= [a-zA-Z] | ?_? | ?:?
NameChar ::= NameStart | [0-9] | ?.? | ?-?
CharData ::= [^<&]*
CharCode ::= ?&? (?#? [0-9]+ | ?lt? | ?amp? | ?quot?) ?;?
S ::= (#32 | #9 | #13 | #10)+

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 08:24:59 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:41 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <3.0.2.32.19991126000518.01029584@pop1.sympatico.ca>
Message-ID: <000201bf37e8$0fa0ccc0$099918d1@docuverse1>

>Agreed, but that doesn't answer the question of "Why XML?".  
>Why not ASN.1, SGML, SML, or a non-standard binary encoded
>XML that might be more suitable over small pipes?  The proxy
>on the last-hop to the cell phone can take care of bidirectional
>conversion, right?

In the very-near future, we will have every darn appliances and
gadgets talking to each other behind our back because the synergy
of them combined will result in far greater level of service.
Any electronic gadgets that doesn't speak the common language will
get booted out of the market quicker than good old Beta from Sony.

As to the question of "Why XML?", the answer is "Why Not?"

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 08:45:11 1999
From: ssahuc at imediation.com (Sebastien Sahuc)
Date: Mon Jun  7 17:17:41 2004
Subject: XML Application Servers
Message-ID: <C10B7E3A3AC3D211804E0000B45EDA8435D3BF@mail.imediation.com>

> I'm using XML as part of a Java servlet-driven framework.  
> The servlets implement the control logic, and interact with EJBs
which implement business logic and DB access.

I like this approach since it the one we deserve!

> The servlet collects output data in a hash-table.  Then, I 
> (plan to) run a
> template-processor, which splices this data into existing XML 
> templates,
> constructing an abstract view of the page. The templating 
> system here is
> similar to HTML templating systems like FreeMarker and 
> WebMacro.  Templates
> don't contain logic, just layout.

Sound similar to the Cocoon publishing framework, expect that your
control logic is handled by the servlet itself. This latter point
should, IMHO, be also XML driven, a la XSP (still from Cocoon), since
logic description -SHOULD NOT- be hard-coded in servlet but rather
scripted, and eventually compiled on the fly by the server processor.
In our project we don't yet clearly seperate the logic from the
content, but our approach is the following : We can express Business
Object behaviour in XML, say simple, actions on a EJB are writen in
XML and result from such action, is still XML, that way, the XSL
processor, in the last step, provide the formatting into HTML for
client that need it. 

May you need more information, don't hesitate.

Sebastien


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



From ht at cogsci.ed.ac.uk  Fri Nov 26 08:53:06 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:17:41 2004
Subject: Linking a XML document to its schema
In-Reply-To: John Aldridge's message of "Thu, 25 Nov 1999 18:12:50 +0000"
References: <John Aldridge's message of "Thu, 25 Nov 1999 13:23:26 +0000"> <f5bg0xuvoa7.fsf@cogsci.ed.ac.uk> <3.0.6.32.19991125132326.00c23d70@mailhost> <3.0.6.32.19991125181250.00bb5db0@mailhost>
Message-ID: <f5bu2m9r5vy.fsf@cogsci.ed.ac.uk>

John Aldridge <john.aldridge@informatix.co.uk> writes:

> >We're certainly trying to improve the situation for use cases like
> >yours in XML Schema.
> 
> That's good news.  Does "XML Schema Composition Task Force Report: Partial
> draft (1.2)" describe the most recent published thinking on this subject?
> I'll go away and read it.

Most recently published -- yes.  Most recent -- no.  Next PWD will
have that.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From robertl1 at home.com  Fri Nov 26 09:10:06 1999
From: robertl1 at home.com (Robert La Quey)
Date: Mon Jun  7 17:17:41 2004
Subject: Any conceptual equivalent? 
Message-ID: <3.0.6.32.19991126010253.0407f680@mail.dt1.sdca.home.com>

Is there any conceputal equivalent in the world of XML 
to the layered view of protocols that the ISO promulgated
so long ago? 

A URL would be good. 

TIA,

Bob La Quey




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



From IndrajitC at catsglobal.co.in  Fri Nov 26 09:20:50 1999
From: IndrajitC at catsglobal.co.in (Indrajit Chaudhuri)
Date: Mon Jun  7 17:17:41 2004
Subject: Software to parse, browse and manipulate DTDs
References: <Pine.GSO.4.10.9911231621030.14988-100000@lutra.sztaki.hu>
Message-ID: <383E516B.C675514C@catsglobal.co.in>

Andras,

You can find a tool XML Authority from Extensibility Inc. which is
freely available for trial. The download site is
"http://www.extensibility.com/products/download_trial.htm" 
Also there is a tool from IBM called XML Generator which is available
from "http://www.alphaworks.ibm.com/tech/xmlgenerator".
Hope they may be of your use.

Thanks,
Indrajit

Andras Micsik wrote:
> 
> I have been looking for a tool that is capable to read in an XML DTD, and
> do some processing on that: create a new XML document and dynamically fill
> it in according to the DTD, browse elements, attribute lists, etc.
> 
> Do you know such tool in Java?
> 
> Thanks in advance,
>                         Andras Micsik
> 
> -----------------------------------------------------------
>   Andras Micsik              micsik@sztaki.hu
>   MTA SZTAKI Hungary         http://www.sztaki.hu/~micsik
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Sophie.Mabilat at apitech.fr  Fri Nov 26 09:40:36 1999
From: Sophie.Mabilat at apitech.fr (Sophie MABILAT)
Date: Mon Jun  7 17:17:41 2004
Subject: DTDs...
Message-ID: <B1C8643B3AB0D21180250000C0B179CD05B662@JUPITER>

Hello everyone,
does anyone know where I can find a DTD or a schema to format a products
list or/and a datasheets list in XML ?
S. MABILAT

--------------------------------------------------------------------
Sophie MABILAT
Sophie.Mabilat@apitech.fr
--------------------------------------------------------------------
APITECH 113, rue Marietton 69009 LYON FRANCE
Tél. : 04 78 43 49 30  Fax : 04 78 83 47 86
--------------------------------------------------------------------
www.apitech.fr
www.zipbee.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Fri Nov 26 09:45:43 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:41 2004
Subject: Handheld computers
References: <A26F84C9D8EDD111A102006097C4CD0D0E90A9@sohos002.ied-support.net>
Message-ID: <004d01bf37f2$fd2a89e0$0b00a8c0@grissom>

> Rick Jelliffe wrote:
> > My first 2.5 years programming was on assembler for real-time
> > controllers,
> > it could take 3 months to write a program and then 3 months to figure
> > out
> > how to make it fit into the PROM.

> Wow ... never thought I'd see that word again!

Which word -- assembler or fit? Both words seem to have disappeared from the
vocabulary of today's programmers.

There was a time that, even when programming a mainframe, you used assembler
to fit code into memory. One of my first assembler programs was an overlay
loader for an IBM mainframe that had all of 32K of memory. During the Apollo
program, big IBM mainframes had 512K. We wrote type IV SVCs (small transient
modules that had to fit in 4K).

35 years ago the American Airlines SABRE system went on the air for the
first time, and handled 40,000 reservations per day, using dual 64K
mainframes.

I wonder how big a TinyXML parser for handhelds will be (or SML).








Assembler was one an necessary skill -- even for the big beastie mainframes.
I once worked on an overlay loader for a mainframe that had 32K of memory.
During the Apollo program,

People think of mainframe computers as big beast with In Eons ago they were
important because even









xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 09:48:49 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:42 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <000001bf37e6$897c6560$099918d1@docuverse1>
Message-ID: <3.0.6.32.19991126092833.00a05e80@gpo.iol.ie>

>
>data ::= (element | CharData | CharCode)*

So a resource consisting of just character data
is a valid SML instance?

So SML will not be a "subset of XML"?

If I have understood you right then this
blows it for me I'm afraid:-(


<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 10:17:10 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:42 2004
Subject: Handheld computers
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90AC@sohos002.ied-support.net>

KenNorth wrote:
> Which word -- assembler or fit?

PROM! Although we were spoilt - we used EPROMs.

(Probably best to knock this thread on the head before the others call
the nostalgia police.)

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Sophie.Mabilat at apitech.fr  Fri Nov 26 10:49:24 1999
From: Sophie.Mabilat at apitech.fr (Sophie MABILAT)
Date: Mon Jun  7 17:17:42 2004
Subject: SML ?!?
Message-ID: <B1C8643B3AB0D21180250000C0B179CD05B666@JUPITER>

Hello,
excuse me but I just subsribed to XML-Dev list and I am new to XML. And when
I read the SGML, XML and SML messages, a question comes to me : what is SML
?
I know XML, SGML, but I don't know anything abourt SML...
Please, help me !
S. MABILAT

---------------------------------------------------------------------
Sophie MABILAT
Sophie.Mabilat@apitech.fr
---------------------------------------------------------------------
APITECH 113, rue Marietton 69009 LYON -FRANCE
Tél. : 04 78 43 49 30  Fax : 04 78 83 47 86
---------------------------------------------------------------------
www.apitech.fr
www.zipbee.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 11:27:06 1999
From: nicmila at vscht.cz (Miloslav Nic)
Date: Mon Jun  7 17:17:42 2004
Subject: SML ?!?
References: <B1C8643B3AB0D21180250000C0B179CD05B666@JUPITER>
Message-ID: <383E6E75.B77F776E@vscht.cz>

My answer: forget about SML.
And thanks for your mail. It precisely demonstrates the danger of
pushing SML at this moment. There may be some virtue in it , I do not
know, but definitively not at this moment.

I mostly speak about XML with people who are not interested in meta
languages but in chemistry, physics, .... 

They are perfectly happy if I say, well if you know that at the
beginning you must have <xxx> and at the end </xxx> and if you want an
attribute you need yyy = "aaa" or yyy = 'aaa' and now you can use XML on
daily basis and there is some more complicated stuff, as you will find
later, .. (and by the time it happens they are hooked)

Please forget about it for a  year.

Sophie MABILAT wrote:
> 
> Hello,
> excuse me but I just subsribed to XML-Dev list and I am new to XML. And when
> I read the SGML, XML and SML messages, a question comes to me : what is SML
> ?
> I know XML, SGML, but I don't know anything abourt SML...
> Please, help me !
> S. MABILAT
> 
> ---------------------------------------------------------------------
> Sophie MABILAT
> Sophie.Mabilat@apitech.fr
> ---------------------------------------------------------------------
> APITECH 113, rue Marietton 69009 LYON -FRANCE
> T?l. : 04 78 43 49 30  Fax : 04 78 83 47 86
> ---------------------------------------------------------------------
> www.apitech.fr
> www.zipbee.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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  
****************************************************************
Support free information exchange: http://zvon.vscht.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martin.schulte at debis.com  Fri Nov 26 11:41:40 1999
From: martin.schulte at debis.com (Schulte, Martin)
Date: Mon Jun  7 17:17:42 2004
Subject: AW: SML ?!?
Message-ID: <4E4F868EFDA2D311AE4F0000F807750E3880@ULNT02>

Hello Sophie,
Hello All,

I just missed some weeks of  discussion here
and have the same problem.
In the XML/SGML community every month/day/hour/second a new abbreviation
occurs.
Many of them might be found at W3C http://www.w3.org/TR


May I try for a translation:
SML:	stupid manipulation language

Regards,
	Martin Schulte

*************************************************************************
 Martin Schulte
 debis Systemhaus GEI
 Magirusstr. 43
 D-89077 Ulm
 Tel:		++49 (0)731-9344-1821                       
 Fax:	++49 (0)731-9344-100
 EMail:	mailto:mschulte@debis.com 
*************************************************************************


> -----Urspr?ngliche Nachricht-----
> Von:	Sophie MABILAT [SMTP:Sophie.Mabilat@apitech.fr]
> Gesendet am:	Freitag, 26. November 1999 11:38
> An:	xml-dev@ic.ac.uk
> Betreff:	SML ?!?
> 
> Hello,
> excuse me but I just subsribed to XML-Dev list and I am new to XML. And
> when
> I read the SGML, XML and SML messages, a question comes to me : what is
> SML
> ?
> I know XML, SGML, but I don't know anything abourt SML...
> Please, help me !
> S. MABILAT
> 
> ---------------------------------------------------------------------
> Sophie MABILAT
> Sophie.Mabilat@apitech.fr
> ---------------------------------------------------------------------
> APITECH 113, rue Marietton 69009 LYON -FRANCE
> T?l. : 04 78 43 49 30  Fax : 04 78 83 47 86
> ---------------------------------------------------------------------
> www.apitech.fr
> www.zipbee.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Fri Nov 26 11:42:18 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:42 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <199911260642152.SM01000@Unknown.>

> At 09:42 AM 11/25/99 +0100, Paul Prescod wrote:
> >Cell phones must increasingly deal with structured information.
> >Therefore cell phones need to deal with XML.
> 
> Agreed, but that doesn't answer the question of "Why XML?".  Why not ASN.1,
> SGML, SML, or a non-standard binary encoded XML that might be more suitable
> over small pipes?  The proxy on the last-hop to the cell phone can take
> care of bidirectional conversion, right?

True enough....

> IMHO, that answer only arrives once you realize that this structured
> information isn't restricted to travelling the client/server path and
> always going through that proxy.  What if I want to send a web page or
> vCard or whatever to another cell phone via IR or Bluetooth, where there's
> no proxy available?  That's where a well-deployed standard matters, and
> *that's* "Why XML?".

Okay, here's the crux of the issue where I'm concerned.  A vCard or some other small 
fragment, that I can grok in this context - fine.  However, I just can't see somebody 
reading a web page (or any other document of substantial size) on their cellphone - not 
even a fairly short page.  It's that whole visual space concern that kicked this thread off 
to begin with; I can read a paragraph or so on a palmtop-sized screen without much 
trouble, or I can look through a short list, but actual *reading*?  Not yet, and so far as I 
can tell, not in the next few years.  The problem is simply one of being unable to track 
complex thoughts on a screen smaller than a playing card and with worse readability.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.aldridge at informatix.co.uk  Fri Nov 26 11:59:08 1999
From: john.aldridge at informatix.co.uk (John Aldridge)
Date: Mon Jun  7 17:17:42 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <199911260642152.SM01000@Unknown.>
Message-ID: <3.0.6.32.19991126115833.00b9b750@mailhost>

At 06:45 26/11/99 -0500, rev-bob@gotc.com wrote:
>> At 09:42 AM 11/25/99 +0100, Paul Prescod wrote:
>> >Cell phones must increasingly deal with structured information.
>> >Therefore cell phones need to deal with XML.

(snip)

>Okay, here's the crux of the issue where I'm concerned.  A vCard or some
other small 
>fragment, that I can grok in this context - fine.  However, I just can't
see somebody 
>reading a web page (or any other document of substantial size) on their
cellphone - not 
>even a fairly short page.  It's that whole visual space concern that
kicked this thread off 
>to begin with ...

Why are you assuming that a web page has to be a document of substantial
size?
-- 
Cheers,
John

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 12:13:42 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:42 2004
Subject: Schema support in parsers?
Message-ID: <000901bf3807$8958fbe0$ab20268a@pc-lrd.bath.ac.uk>

Hi,

Is anyone aware of any parsers which support the latest Schema 
draft?

I know xml4j had partial support for an earlier draft, but I was 
curious whether anything else was available?

Failing that, how about a tool(s) to go from a Schema to a DTD?
(accepting that some schema constructs can be expressed in 
a DTD).

L.

==================================================================
    "Never Do With More, What Can Be Achieved With Less"
				---William of Occam
==================================================================
Leigh Dodds                             Eml:  ldodds@ingenta.com
ingenta ltd                             Tel:  +44 1225 826619
BUCS Building, University of Bath       Fax:  +44 1225 826283

HomePage :				 	http://www.bath.ac.uk/~ccslrd/
WebLog   :			     http://weblogs.userland.com/eclectic/
==================================================================


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



From martind at netfolder.com  Fri Nov 26 12:31:12 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:42 2004
Subject: XML Application Servers
In-Reply-To: <m3so1tzohs.fsf@picasso.o3.co.uk>
Message-ID: <NBBBJPGDLPIHJGEHAKBAGELGEHAA.martind@netfolder.com>

Hi Matthew,

Matthew said:
I'm using XML as part of a Java servlet-driven framework.  The servlets
implement the control logic, and interact with EJBs which implement
business logic and DB access.

The servlet collects output data in a hash-table.  Then, I (plan to) run a
template-processor, which splices this data into existing XML templates,
constructing an abstract view of the page. The templating system here is
similar to HTML templating systems like FreeMarker and WebMacro.  Templates
don't contain logic, just layout.

Finally XSLT transformtion into HTML, rather than delivering XML to the
client.

Has anyone done something similar?

Didier reply:
We are building something similar to this. However, the XML server checks
the client's version and if the server detect that it is an XML server it
sends the XML+XSL or XML+CSS to the client. Otherwise the XML document is
transformed server side. We also use XML themplates that we call XSP
documents.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 12:45:49 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun  7 17:17:42 2004
Subject: [SML] Preliminary EBNF for SML
Message-ID: <199911261240.MAA24954@nag.co.uk>



Name ::= NameStart (NameChar)*
NameStart ::= [a-zA-Z] | '_' | ':'
NameChar ::= NameStart | [0-9] | '.' | '-'

Given all the work that's currently going on to internationalise the web
(and computing in general) and remove historic English bias, is it
really politically or culturally acceptable to restrict element names to
the English alphabet? If SML is only for English you could restrict the
character data to be ascii as well to save on processing utf8
characters.  If it isn't only for English then the above would
presumably be one of many SML, SML-EN, and you would expect to see
similar variants allowing element names in French or Russian, or
Japanese?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 12:51:01 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:17:42 2004
Subject: XML Application Servers
Message-ID: <8DCB90532FF7D211B34400805FD48853AFE95F@SENMAIL3>

Anyone building this kind of thing on a IIS/ASP/COM  based technology?

I am interested in the different ways people doing this have managed to
integrated this technology with the XML technologies.

Also, anyone using Tamino XML Server? What experiences have you had?

cheers,
steven

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Didier PH Martin [SMTP:martind@netfolder.com]
> Sent:	26 November 1999 12:28
> To:	Mike Williams; Matthew Gertner
> Cc:	XML Developers List
> Subject:	RE: XML Application Servers
> 
> Hi Matthew,
> 
> Matthew said:
> I'm using XML as part of a Java servlet-driven framework.  The servlets
> implement the control logic, and interact with EJBs which implement
> business logic and DB access.
> 
> The servlet collects output data in a hash-table.  Then, I (plan to) run a
> template-processor, which splices this data into existing XML templates,
> constructing an abstract view of the page. The templating system here is
> similar to HTML templating systems like FreeMarker and WebMacro.
> Templates
> don't contain logic, just layout.
> 
> Finally XSLT transformtion into HTML, rather than delivering XML to the
> client.
> 
> Has anyone done something similar?
> 
> Didier reply:
> We are building something similar to this. However, the XML server checks
> the client's version and if the server detect that it is an XML server it
> sends the XML+XSL or XML+CSS to the client. Otherwise the XML document is
> transformed server side. We also use XML themplates that we call XSP
> documents.
> 
> Cheers
> Didier PH Martin
> mailto:martind@netfolder.com
> http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Juliane.Harbarth at softwareag.com  Fri Nov 26 13:06:12 1999
From: Juliane.Harbarth at softwareag.com (Harbarth, Juliane)
Date: Mon Jun  7 17:17:42 2004
Subject: SML ?!?
Message-ID: <C23163F98473D311874C0008C7E62107F2EEEA@daemsg02.software-ag.de>



> what is SML

SML stands for Simple Markup Language, it is an attempt
and/or an idea to simplify XML, e.g. by creating a new
standard that contains just a subset of XML.
This is supposed to make live easier for people/devices
who/that consume XML. 

Juliane.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 13:13:21 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun  7 17:17:42 2004
Subject: Any conceptual equivalent? 
In-Reply-To: <3.0.6.32.19991126010253.0407f680@mail.dt1.sdca.home.com>
Message-ID: <Pine.GHP.4.21.9911261258340.2580-100000@mail.ilrt.bris.ac.uk>




On Fri, 26 Nov 1999, Robert La Quey wrote:

> Is there any conceputal equivalent in the world of XML 
> to the layered view of protocols that the ISO promulgated
> so long ago? 

There are a number of perspectives on this.

A few I mostly agree with...

	http://www.w3.org/TR/NOTE-rdfarch
	http://www.w3.org/TR/schema-arch
	http://www.w3.org/1999/04/WebData
	http://www.egroups.com/group/xml-dev/12791.html

Dan


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



From martind at netfolder.com  Fri Nov 26 14:22:15 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:42 2004
Subject: XML Application Servers
In-Reply-To: <8DCB90532FF7D211B34400805FD48853AFE95F@SENMAIL3>
Message-ID: <NBBBJPGDLPIHJGEHAKBAAELJEHAA.martind@netfolder.com>

Hi Steven,

Steven said:
Anyone building this kind of thing on a IIS/ASP/COM  based technology?

I am interested in the different ways people doing this have managed to
integrated this technology with the XML technologies.

Also, anyone using Tamino XML Server? What experiences have you had?

Didier reply:
We are currently building this XML server as an IIS extension (later on as
an extension to Apache). We obviously do not use the ASP technology which is
reducing the performance. The goal of the IIS extension is:
a) check the client's browser version, if it is IE 5 then send the XML
document as is. Otherwise do the transformation server with either a XSL or
DSSSL engine.
b) the XML document may not be associated to a style sheet, in this case,
the server look for the document type in a table and associate a style sheet
to the document.

Actually, it works for outgoing process only.

If you use ASP technology instead of an XML IIS extension, then you are
facing:
a) the overhead of the ASP interpretation
b) the overhead of the script language interpretation (ex: javaScipt or
VBScript used a script engines by ASP)

In fact, by using ASP technologies you have two interpretation level that
are superfluous to the process of
a) sending an XML document to a XML browser
b) associating a style sheet to an XML document before sending it to the
browser
c) doing style sheet processing on the server is there is a need to do so.

We came to that conclusion after having created, for our needs, an XML
server with ASP, the MSXML XML/XSL engine and VBScript as the script
language instantiating the MSXML engine to perform the transformation job.

So, at first we used IIS, ASP and COM technologies but came to the
conclusion that ASP was causing superfluous processing. So we moved to IIS,
Talva XML IIS extension and COM to improve the performance and remove the
unnecessary bottlenecks. Also, the secondary advantage is that now, the
server respond with this kind of URL http://www.mydomain.com/mydocument.xml
(of course, MyDomain and Mydocument are imaginary names). This is an
improvement on our previous URLS which where
http://www.mydomain.com/xml.asp?file="mydir/myfile.xml".

The Talva XML IIS extension is written in C++ and compiled with optimisation
for Pentium to reach a maximum performance. We are now, integrating the
capability to use Java processors for XSL processing. Some Java XSL
processor are more up to date and conform to the latest W3C recommendations
that is MSXML. This provides more freedom of choice for the XSLT processor.
Among the actual Java XSLT providers, you have: IBM, oracle, Indev and James
Clark. The VM is mounted at the same time as the IIS server is mounted and
then the overhead of loading the VM for each processing is removed. This is
not a servlet though. It is a XML engine aware of the XSLT processor
packaged as COM objects or as Java classes and knowing how to interface with
each one.

A note about the Java processor:
As soon as an XML document has been processed, the Java classes are compiled
into native machine code by the Just in time compiler. Thus, after the first
usage of the Java XSLT engine, this latter is compiled and more efficient.
We used the Microsoft VM for its exeptional JIT processing and overall
performance. Also, because it is, in fact a COM component.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

Cheers


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 15:07:18 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:42 2004
Subject: Any conceptual equivalent? 
Message-ID: <006201bf3823$62dcc6b0$43f96d8c@NT.JELLIFFE.COM.AU>

And on the subject of the OSI reference model (the ISO layered
protocols)
there is a very interesting book by Carl Malamud, the Internet bigwig.
Apart from laudable recommendations about the Cafe Hernandez in
Sydney, it says that Internet succeeds on what is actually a 4-layer
model:
he raises the question that there can be too much layering
(for reasons of implementations efficiency, chances of bugs in interface
code, etc).

So slicing the pie horizontally is not always the best way!

Rick Jelliffe

-----Original Message-----
From: Dan Brickley <Daniel.Brickley@bristol.ac.uk>
To: Robert La Quey <robertl1@home.com>
Cc: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk>
Date: Friday, 26 November 1999 21:39
Subject: Re: Any conceptual equivalent?


>
>
>
>On Fri, 26 Nov 1999, Robert La Quey wrote:
>
>> Is there any conceputal equivalent in the world of XML
>> to the layered view of protocols that the ISO promulgated
>> so long ago?
>
>There are a number of perspectives on this.
>
>A few I mostly agree with...
>
> http://www.w3.org/TR/NOTE-rdfarch
> http://www.w3.org/TR/schema-arch
> http://www.w3.org/1999/04/WebData
> http://www.egroups.com/group/xml-dev/12791.html
>
>Dan
>
>
>xml-dev: A list for W3C XML Developers. To post,
mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From schnitz at overflow.de  Fri Nov 26 15:11:49 1999
From: schnitz at overflow.de (Sebastian Schnitzenbaumer)
Date: Mon Jun  7 17:17:43 2004
Subject: XML Application Servers
In-Reply-To: <m3so1tzohs.fsf@picasso.o3.co.uk>
References: Matthew Gertner's message of "Thu, 25 Nov 1999 10:25:08 +0100"
Message-ID: <199911261611.RAA02915@server.overflow.de>

Hi Mike,

>   >>> On Thu, 25 Nov 1999 10:25:08 +0100,
>   >>> "Matthew" == Matthew Gertner <matthew@praxis.cz> wrote:
> 
>   Matthew> A question: who out there is developing applications delivering
>   Matthew> XML from a server platform? How are you doing it?
> 
> I'm using XML as part of a Java servlet-driven framework.  The servlets
> implement the control logic, and interact with EJBs which implement
> business logic and DB access.  
> 
> The servlet collects output data in a hash-table.  Then, I (plan to) run a
> template-processor, which splices this data into existing XML templates,
> constructing an abstract view of the page. The templating system here is
> similar to HTML templating systems like FreeMarker and WebMacro.  Templates
> don't contain logic, just layout.
> 
> Finally XSLT transformtion into HTML, rather than delivering XML to the
> client.
> 
> Has anyone done something similar?

I watched your conversation on XML-dev. I'm leading the Mozquito 
Project and my team is currently planning to develop an IIS 
extension and Apache module similar in function as you described.

Our core technology is the transformation of XML into JavaScript. 
By doing this, we can process new markup languages in existing 
browsers. Currently, we have designed and implemented an XML 
grammar called XHTML-FML, which is XML-based HTML 4 
(XHTML) with 14 additional Forms Markup Language (FML) tags for 
improved web forms and dynamic web pages.

We have extended XHTML so authors do not need to write 
additional functionality in JavaScript/VBScript. Instead, dynamic 
features are now part of HTML, making it easier to author and 
dynamically generate large forms and dynamic web pages on the 
server.

Currently, under http://www.mozquito.org, you can download a 
client-side editor that allows you to write and validate XHTML-FML, 
and when viewing the file in the browser, the XHTML-FML 
document is being automatically transformed into cross-browser 
JavaScript so that the browser can process the 14 additional tags.

While the editor is targetted to web designer and HTML writers who 
wish to develop single, fancy web pages, our next product will be a 
server extension. This will allow to transform pure XML into XHTML-
FML via XSL or DSSSL, and then the XHTML-FML is being 
transformed into cross-browser JavaScript on-the-fly for optimal 
results on version 4 browsers.

FML could be also used to edit XML files in the browser. One could 
think of a scenario where normally an XML file is being transformed 
into plain XHTML, but when someone uses the "administration 
mode", the XML files are transformed into XHTML-FML where every 
text and component becomes a textarea or form control. One could 
then edit the document in the browser, and send the result via 
submit back to the server.

So I justed wanted to ask what your plans are and whether we 
could possibly work together on this, since there seems to be quite 
some overlap between our two projects?

Thanks,

Sebastian


---
Stack Overflow AG
Phone: +49-89-767363-70

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 15:17:07 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:43 2004
Subject: [UseableServerSML+i18n] Preliminary EBNF for UseableServerSML+i18n
Message-ID: <006501bf3824$d131e770$43f96d8c@NT.JELLIFFE.COM.AU>

This message is for those interested in UseableServer SML+i18n.  I would
like
to suggest that we use the [UseableServerSML+i18n] prefix to identify
our
messages for filtering purpose.

Below is a preliminary version of EBNF for UseableServerSML+i18n.  I
would
appreciate your comments on it.  Notable changes from SML are

1. Addition of "server instruction" tags, with delimiters <? and ?>
2. Support for languages other than Bahasa Indonesia,
Bahasa Malaysia, Swahili, Hawaiian and Hare Moto.
3. Support for comments
4. Support for allowing graphs as well as trees of data
5. Easy embedding of program code and text with delimiters.

data ::= ... err, refer XML 1.0 spec


Best,

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 15:41:19 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:17:43 2004
Subject: XML Application Servers
Message-ID: <8DCB90532FF7D211B34400805FD48853AFE969@SENMAIL3>

Sure,it is http://www.softwareag.com/tamino

Supposed to be one of the best !?

cheers
steven

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Didier PH Martin [SMTP:martind@netfolder.com]
> Sent:	26 November 1999 14:19
> To:	Steven Livingstone, ITS, SENM; xml-dev@ic.ac.uk
> Subject:	RE: XML Application Servers
> 
> Hi Steven,
> 
> Steven said:
> Anyone building this kind of thing on a IIS/ASP/COM  based technology?
> 
> I am interested in the different ways people doing this have managed to
> integrated this technology with the XML technologies.
> 
> Also, anyone using Tamino XML Server? What experiences have you had?
> 
> Didier reply:
> We are currently building this XML server as an IIS extension (later on as
> an extension to Apache). We obviously do not use the ASP technology which
> is
> reducing the performance. The goal of the IIS extension is:
> a) check the client's browser version, if it is IE 5 then send the XML
> document as is. Otherwise do the transformation server with either a XSL
> or
> DSSSL engine.
> b) the XML document may not be associated to a style sheet, in this case,
> the server look for the document type in a table and associate a style
> sheet
> to the document.
> 
> Actually, it works for outgoing process only.
> 
> If you use ASP technology instead of an XML IIS extension, then you are
> facing:
> a) the overhead of the ASP interpretation
> b) the overhead of the script language interpretation (ex: javaScipt or
> VBScript used a script engines by ASP)
> 
> In fact, by using ASP technologies you have two interpretation level that
> are superfluous to the process of
> a) sending an XML document to a XML browser
> b) associating a style sheet to an XML document before sending it to the
> browser
> c) doing style sheet processing on the server is there is a need to do so.
> 
> We came to that conclusion after having created, for our needs, an XML
> server with ASP, the MSXML XML/XSL engine and VBScript as the script
> language instantiating the MSXML engine to perform the transformation job.
> 
> So, at first we used IIS, ASP and COM technologies but came to the
> conclusion that ASP was causing superfluous processing. So we moved to
> IIS,
> Talva XML IIS extension and COM to improve the performance and remove the
> unnecessary bottlenecks. Also, the secondary advantage is that now, the
> server respond with this kind of URL
> http://www.mydomain.com/mydocument.xml
> (of course, MyDomain and Mydocument are imaginary names). This is an
> improvement on our previous URLS which where
> http://www.mydomain.com/xml.asp?file="mydir/myfile.xml".
> 
> The Talva XML IIS extension is written in C++ and compiled with
> optimisation
> for Pentium to reach a maximum performance. We are now, integrating the
> capability to use Java processors for XSL processing. Some Java XSL
> processor are more up to date and conform to the latest W3C
> recommendations
> that is MSXML. This provides more freedom of choice for the XSLT
> processor.
> Among the actual Java XSLT providers, you have: IBM, oracle, Indev and
> James
> Clark. The VM is mounted at the same time as the IIS server is mounted and
> then the overhead of loading the VM for each processing is removed. This
> is
> not a servlet though. It is a XML engine aware of the XSLT processor
> packaged as COM objects or as Java classes and knowing how to interface
> with
> each one.
> 
> A note about the Java processor:
> As soon as an XML document has been processed, the Java classes are
> compiled
> into native machine code by the Just in time compiler. Thus, after the
> first
> usage of the Java XSLT engine, this latter is compiled and more efficient.
> We used the Microsoft VM for its exeptional JIT processing and overall
> performance. Also, because it is, in fact a COM component.
> 
> Cheers
> Didier PH Martin
> mailto:martind@netfolder.com
> http://www.netfolder.com
> 
> Cheers
> 
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 15:52:37 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:17:43 2004
Subject: XML Application Servers
Message-ID: <8DCB90532FF7D211B34400805FD48853AFE96A@SENMAIL3>

An ISAPI extension is probably best if your server/application is devoted to
XML, as your clearly is (yes?).

Can you perform business validation etc in this way? As in a typical n-teir
application.
So you want to write XML pages back for an application, after validating
business rules and getting the resultsd from the database.

If so, does the extension or your COM objects dynamically create the XML
document from the result set?
Do you have a URL for the extension?

Sounds good !

cheers,
steven

PS. You can get round the XML problem in ASP, if you map the .xml extension
to the asp.dll. I have done this (for .xsl) to dynamically create .xsl
stylesheets based on Site Server personalization attributes !

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Didier PH Martin [SMTP:martind@netfolder.com]
> Sent:	26 November 1999 14:19
> To:	Steven Livingstone, ITS, SENM; xml-dev@ic.ac.uk
> Subject:	RE: XML Application Servers
> 
> Hi Steven,
> 
> Steven said:
> Anyone building this kind of thing on a IIS/ASP/COM  based technology?
> 
> I am interested in the different ways people doing this have managed to
> integrated this technology with the XML technologies.
> 
> Also, anyone using Tamino XML Server? What experiences have you had?
> 
> Didier reply:
> We are currently building this XML server as an IIS extension (later on as
> an extension to Apache). We obviously do not use the ASP technology which
> is
> reducing the performance. The goal of the IIS extension is:
> a) check the client's browser version, if it is IE 5 then send the XML
> document as is. Otherwise do the transformation server with either a XSL
> or
> DSSSL engine.
> b) the XML document may not be associated to a style sheet, in this case,
> the server look for the document type in a table and associate a style
> sheet
> to the document.
> 
> Actually, it works for outgoing process only.
> 
> If you use ASP technology instead of an XML IIS extension, then you are
> facing:
> a) the overhead of the ASP interpretation
> b) the overhead of the script language interpretation (ex: javaScipt or
> VBScript used a script engines by ASP)
> 
> In fact, by using ASP technologies you have two interpretation level that
> are superfluous to the process of
> a) sending an XML document to a XML browser
> b) associating a style sheet to an XML document before sending it to the
> browser
> c) doing style sheet processing on the server is there is a need to do so.
> 
> We came to that conclusion after having created, for our needs, an XML
> server with ASP, the MSXML XML/XSL engine and VBScript as the script
> language instantiating the MSXML engine to perform the transformation job.
> 
> So, at first we used IIS, ASP and COM technologies but came to the
> conclusion that ASP was causing superfluous processing. So we moved to
> IIS,
> Talva XML IIS extension and COM to improve the performance and remove the
> unnecessary bottlenecks. Also, the secondary advantage is that now, the
> server respond with this kind of URL
> http://www.mydomain.com/mydocument.xml
> (of course, MyDomain and Mydocument are imaginary names). This is an
> improvement on our previous URLS which where
> http://www.mydomain.com/xml.asp?file="mydir/myfile.xml".
> 
> The Talva XML IIS extension is written in C++ and compiled with
> optimisation
> for Pentium to reach a maximum performance. We are now, integrating the
> capability to use Java processors for XSL processing. Some Java XSL
> processor are more up to date and conform to the latest W3C
> recommendations
> that is MSXML. This provides more freedom of choice for the XSLT
> processor.
> Among the actual Java XSLT providers, you have: IBM, oracle, Indev and
> James
> Clark. The VM is mounted at the same time as the IIS server is mounted and
> then the overhead of loading the VM for each processing is removed. This
> is
> not a servlet though. It is a XML engine aware of the XSLT processor
> packaged as COM objects or as Java classes and knowing how to interface
> with
> each one.
> 
> A note about the Java processor:
> As soon as an XML document has been processed, the Java classes are
> compiled
> into native machine code by the Just in time compiler. Thus, after the
> first
> usage of the Java XSLT engine, this latter is compiled and more efficient.
> We used the Microsoft VM for its exeptional JIT processing and overall
> performance. Also, because it is, in fact a COM component.
> 
> Cheers
> Didier PH Martin
> mailto:martind@netfolder.com
> http://www.netfolder.com
> 
> Cheers

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Fri Nov 26 16:17:56 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:43 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
References: <199911260642152.SM01000@Unknown.>
Message-ID: <006701bf3829$cd4307c0$96d88dce@sagus.com>


----- Original Message -----
From: <rev-bob@gotc.com>
To: xml <xml-dev@ic.ac.uk>
Sent: Friday, November 26, 1999 6:45 AM
Subject: re: Re: Why I Hate Palmtops (was: Re: SGML, XML and SML)

>.  However, I just can't see somebody  reading a web page (or any other >
document of substantial size) on their cellphone - not
> even a fairly short page.  It's that whole visual space concern that
kicked this
> thread off  to begin with

The way I see it, if the underlying source for web pages is coded in some
XML-like markup language, then stylesheets driving the WML output can
present only those elements that convey the essence of the page ... no
sidebars, supporting quotations, banner ads, etc.  You won't see the HTML
page broken up into cellphone-sized screens (which I agree is pointless).

This requires both some technology (which is rapidly becoming available) and
a change in the culture of Web page authoring, which will come if the market
demands it.  I suspect that the initial market will be for cellphone data
and short messages, not more Web-like pages, but that will seed demand for
WML-friendly markup across the board.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Fri Nov 26 16:18:12 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:43 2004
Subject: [SML] Re: SML ?!?
References: <B1C8643B3AB0D21180250000C0B179CD05B666@JUPITER> <383E6E75.B77F776E@vscht.cz>
Message-ID: <006f01bf3829$d9c45300$96d88dce@sagus.com>

See http://www.xml.com/pub/1999/11/sml/index.html for an article describing
the SML idea and the controversy surrounding it.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 16:46:28 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:43 2004
Subject: [SML] Re: SML ?!?
References: <B1C8643B3AB0D21180250000C0B179CD05B666@JUPITER> <383E6E75.B77F776E@vscht.cz> <006f01bf3829$d9c45300$96d88dce@sagus.com>
Message-ID: <00c001bf382d$c83df290$eb020a0a@bowstreet.com>

> See http://www.xml.com/pub/1999/11/sml/index.html for an article
describing
> the SML idea and the controversy surrounding it.

I noted with interest (and disagreement) the technical arguments against
attributes.

If XML is used for representing tree structures or property/value pairs,
then, yes, attributes can give way to child elements.

But if XML is used for *markup*, attributes make sense and should not be
replaced by child elements.
(I have made this point whenever attribute vs element discussions have
arisen).

Why? Because in *markup* there is a distinction between content and markup.
The character data content of an element is content. The value of an
attribute is markup. Attributes, like other markup, provide information in
addition to the textual content.

For example, a person thinking how to express the fact that Max is a dog
that is black might use:

<dog>
    <name>Max</name>
    <colour>black</colour>
</dog>

However, a person wanting to markup the text "Max" indicating that he is a
black dog couldn't do the above. They might, instead, use:

<dog colour="black">Max</dog>

So if XML is being used for marking up existing textual content, attributes
have a definite place.

James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
FOP / XMLINFO.COM / XMLSOFTWARE.COM / SCHEMA.NET / XSLINFO.COM
<pipe>Ceci n'est pas une pipe</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 17:25:04 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:43 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90B5@sohos002.ied-support.net>

Michael Champion wrote:
> The way I see it, if the underlying source for web pages is 
> coded in some
> XML-like markup language, then stylesheets driving the WML output can
> present only those elements that convey the essence of the page ... no
> sidebars, supporting quotations, banner ads, etc.  You won't 
> see the HTML
> page broken up into cellphone-sized screens (which I agree is 
> pointless).

I sort of agree. I think that this is where XSL-FO will come in. XML
will first be transformed to device-independent layout, and then that
will be transformed to HTML/XHTML for the Web, WML for the mobile phone
(for now), PostScript for print, Director for CD-ROM publications, FDML
(Fridge Door Mark-up Language) for showing on the front of your fridge
and BOEML (Back Of Envelope Mark-up Language) for developing radical
ideas.

That way, if your XML source data changes you only change one XSLT
transform - to the FO. And adding a new device only involves saying how
a particular FO declaration works for that device. (Note that means only
once *ever*, not once per XML document or once per project. You only
need to say how FO instructions are rendered on that device once - we
could all share the same XSLT file.)

This would make a WAP gateway into a simple XSL-FO to WML mapping
server, and the rest of us wouldn't have to learn WML.

It also raises an issue which I'm quite into at the moment, that of
chaining transformations.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From robin at isogen.com  Fri Nov 26 17:36:06 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:43 2004
Subject: [SML] Re: SML ?!?
In-Reply-To: <00c001bf382d$c83df290$eb020a0a@bowstreet.com>
Message-ID: <Pine.GSO.3.96.991126110803.465N-100000@grind>


On Fri, 26 Nov 1999, James Tauber wrote:

> > See http://www.xml.com/pub/1999/11/sml/index.html for an article
> > describing the SML idea

[James]
> I noted with interest (and disagreement) the technical arguments against
> attributes.

I had a similar feeling about the 'arguments against attributes' - I think
it drew a conclusion without having engaged the matter adequately.

1. Yeah, the SGML/XML notion of an "attribute" is badly broken
2. A markup language used in part as a data modelling language certainly
   should be able to distinguish notationally and conceptually between
   an object ('element') and an attribute.
3. Just throwing out the SGML/XML attribute isn't the right solution,
   in my judgment.

[...]
> 
> Why? Because in *markup* there is a distinction between content and markup.
> The character data content of an element is content. The value of an
> attribute is markup. Attributes, like other markup, provide information in
> addition to the textual content.
> 
> For example, a person thinking how to express the fact that Max is a dog
> that is black might use:
> 
> <dog>
>     <name>Max</name>
>     <colour>black</colour>
> </dog>
> 
> However, a person wanting to markup the text "Max" indicating that he is a
> black dog couldn't do the above. They might, instead, use:
> 
> <dog colour="black">Max</dog>
> 
> So if XML is being used for marking up existing textual content, attributes
> have a definite place.

Even this example, while instructive and illustrative, does not begin to
address the deeper issues.  For example, whatever the SGML/XML standards
may say formally about "content" versus "non-content", and irrespective
of whether these definitions accord well with users notions of "content"
in different application domains (a HUGE usability concern), we have in
TEI for example, a markup strategy for correcting a known or suspected
error in some text, with sic/corr tags:

I write:  As Job Bosak astutely observed
You encode:  <p>As <corr sic="Job">Jon</corr> Bosak astutely observed

(or something like this -- see TEI's mirror tags)

In practice, trying to declare in advance what may be reckoned as
"content" is extremely difficult (attribute value literals in some
contexts but not others; most all PCDATA but not all, etc.)

The definitions I've seen are break very quickly, when one considers
the range of applications and users WRT SGML/XML: it's not "what
is seen vs. what is not seen"; nor "what's really in the 'text'
vs. what is metadata".  All such distinctions I've seen are
broken, and non-repairable.  Especially if one is concerned to
uphold the notion of a descriptive markup language as having
no pre-defined application level processing semantics.

-rcc



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



From KenNorth at email.msn.com  Fri Nov 26 18:11:26 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:43 2004
Subject: Any conceptual equivalent? 
References: <3.0.6.32.19991126010253.0407f680@mail.dt1.sdca.home.com>
Message-ID: <009f01bf3839$ed3f4060$0b00a8c0@grissom>

This bounced back so I'm re-sending. Pardon me if it shows up twice.

> Is there any conceputal equivalent in the world of XML
> to the layered view of protocols that the ISO promulgated
> so long ago?

The ISO communication protocols are layered so that higher-level protocols
build
on, and use, lower-level protocols.  Conceptually they are like a series of
envelopes, with the actual information content contained inside frames
having address information. There is overhead involved in messages -- you
wrap the content with message headers, CRCs, and so on. To get to the core
content, you must extract it from the envelope (the framing data used to
ensure delivery).

XML documents are self-describing. so they contain additional information
besides the core content. You use tags to wrap the core content, so like
message processing, there is a process of extracting the content from its
framing information. Of course, XML can be also sent across the wire -- in
which case it fits in the envelope analogy where you have to strip off CRCs,
etc. before dealing with the XML document.





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



From KenNorth at email.msn.com  Fri Nov 26 19:08:34 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:43 2004
Subject: Handheld computers
References: <A26F84C9D8EDD111A102006097C4CD0D0E90AC@sohos002.ied-support.net>
Message-ID: <00ce01bf383b$4eda0480$0b00a8c0@grissom>

Subject: RE: Handheld computers


> KenNorth wrote:
> > Which word -- assembler or fit?
>
> PROM! Although we were spoilt - we used EPROMs.
>
> (Probably best to knock this thread on the head before the others call
> the nostalgia police.)

I'm not sure EEPROMs are irrelevant.

Some form of PROM or ROM is a good place to put the parser if you're talking
about devices with limited memory.



================== Ken North =============================
http://ourworld.compuserve.com/homepages/Ken_North
ken_north@compuserve.com  71301.1306@compuserve.com  KenNorth@msn.com
Ken North Computing   2604B El Camino Real, #351
Carlsbad, CA 92008-1214 Fax:760-729-5127 Ph:760-757-2362
===========================================================





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



From KenNorth at email.msn.com  Fri Nov 26 19:34:04 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:44 2004
Subject: XML Application Servers
References: Matthew Gertner's message of "Thu, 25 Nov 1999 10:25:08 +0100" <199911261611.RAA02915@server.overflow.de>
Message-ID: <014801bf3845$7e696b00$0b00a8c0@grissom>

<< Our core technology is the transformation of XML into JavaScript.

Interesting.

The US Department of Defense is considering a ban on JavaScript and VBScript
(due to hacking), so an XML > HTML transformation would be more appealing to
DoD webmasters.







xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 19:40:25 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:17:44 2004
Subject: XML:  Still Just HypedWebStuff
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk> <38399EAD.58EB4FDE@prescod.net> <m31z9ho1hg.fsf_-_@localhost.localdomain> <383A900C.F3BBA15C@prescod.net> <m3pux0t0a7.fsf@localhost.localdomain> <383C1863.6CE3@hiwaay.net> <383CFF04.56BA9193@praxis.cz> <383D5EA2.2988@hiwaay.net> <m3vh6qqq62.fsf@localhost.localdomain>
Message-ID: <383EE148.6BDC@hiwaay.net>

David Megginson wrote:
> 
> Len Bullard <cbullard@hiwaay.net> writes:
> 
> > What we are seeing is a hype that XML has some magical effect on the
> > bottom line, but the dirty secret is it costs as much or more, and just
> > like SGML, if I need consultants and BizPartners just to implement it,
> > it is a failed technology.
> 
> Both statements are false: SGML and XML don't do much, and they don't
> cost much.

Contentious, perhaps, but not false. It isn't what they do;  it is what 
we do with them and what that costs.  What we do can be done many ways
so why 
should large businesses consider moving away from working 
solutions to solutions that require retooling?   Again, cost justify it.
 
> High-volume custom publishing systems, complex interactive databases,
> document management systems with word-level granularity, large
> customizable dynamically-constructed Web sites, and other such goodies
> *do* cost a lot, and they'd cost a lot with or without SGML or XML
> (you probably save a trivial amount because you can use OTS software
> for a few of the tasks).

Yes, but they don't cost as much as they used to.  With or without 
SGML/XML, the cost of these systems is coming down.  Why?  Economy of
scale 
mostly, plus, being able to buy a unified framework (eg, MS) for 
enterprise-capable deployment certainly helps.  The fact of the ubiquity 
of that framework makes it a lot cheaper to sell; the fact of the 
application of a unified lexical definition at every level of the 
system (eg, SQLServer to Client), makes it cheaper.  The fact that 
competitors such as Oracle support it as well make it cheaper.  The 
fact that they may do it in incompatible ways will certainly add 
cost back in, but the costs may be sustainable if the transforms 
are cheap enough.  We would like competition as well to reduce 
cost, but that one is a reliability problem.  

XML is part of the solution to getting TCO under control, but 
it also comes with a price and that price is high initially.

> That's not a bad thing, as long as people are building those systems
> for the right reasons (they need them) and not for the wrong reasons
> (they think that something about SGML or XML compells them to).

Need them?  Nothing about HTML compelled us to use it.  Why do we use
it?  
Economy of scale.  Hype and free software help, but the money only 
came once the economy of scale could be demonstrated.  Attaching a 
stigma to competitors helped, but that's business politics.  The W3C and
the 
HTML community have paid for that considering they have adopted the very 
tech they were actively stigmatizing.  We all have those moments.
 
> I'm really, really tired of people writing that XML is expensive.
> That's like saying that tires are expensive because you have to buy a
> Jaguar to put on top of them.

There is that training thing.  A Jag isn't a good example; such a 
poorly designed and overrated sports car.  Take a 
Porsche.  High performance, high cost.  Not drivable unless someone 
spends some time teaching one how to handle it.  Otherwise, a dangerous 
car to the driver and anyone they share a highway with.   The gas costs 
don't go up; the insurance does.  Bad business decision.

TCO (Total Cost of Ownership) is what one should look at to cost justify 
SGML/XML.  The costs on the front end, although better than they used 
to be, are still stiff.  Anyone who fields large COTS systems to large 
organizations (has a current successful product line) can't simply jump 
into XML.  There are skills, tools, the ever elusive mindshare, industry 
concepts and requirements expressed in requests for proposals, testing
for performance 
(load test IIS and watch where it breaks - it does break),
synchonization, 
security, and so forth to pay for.  By the time that is all worked out
and can 
pass a FAT, quite a lot of money has been spent.  Now, that reliability 
thing Gates is talking about is a fairly old problem where I learned 
SGML: Integrated Logistics Systems (ILS), and until it is solved at 
the component level, integrating very large systems remains problematic 
and XML remains tech hyped but unproven.  XML helps this problem only if 
the information shared can be proven valid independent of the
implementation 
of the component.  That DTD thing, easy.... but the components?

TCO comes down when reliable components can be spec'd, 
tested, shared, delivered and sustained.  The payoff of markup comes
when the views 
within an organization, across a contractually bound set of performing 
organizations, and across the lifecycle of the deliverable are
considered. 
The payoff is there, but it won't be unless the tech scales across both 
the views of the organization and the schedules, and the basis for 
negotiating records of authority are proven and shared.

Think Record Of Authority.  A Semantic Web is just more email without 
that concept.  Machines do not have "meaning".  They cannot make
agreements, 
or can they?  That one is the fun problem these days.

BTW:  arrays in schemas or let's drop the schemas and try something 
without religious beliefs in the design.  The well-formed schema 
concept has merit, so good; but the data structures need to be 
discussed openly.  Applications such as X3D have requirements for the 
arrays.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 26 20:09:50 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:44 2004
Subject: XML:  Still Just HypedWebStuff
In-Reply-To: <383EE148.6BDC@hiwaay.net>
References: <Pine.GHP.4.21.9911220901000.8349-100000@mail.ilrt.bris.ac.uk>
	<38399EAD.58EB4FDE@prescod.net>
	<m31z9ho1hg.fsf_-_@localhost.localdomain>
	<383A900C.F3BBA15C@prescod.net>
	<m3pux0t0a7.fsf@localhost.localdomain>
	<383C1863.6CE3@hiwaay.net>
	<383CFF04.56BA9193@praxis.cz>
	<383D5EA2.2988@hiwaay.net>
	<m3vh6qqq62.fsf@localhost.localdomain>
	<383EE148.6BDC@hiwaay.net>
Message-ID: <14398.59574.252359.403882@localhost.localdomain>

Len Bullard writes:

 > Contentious, perhaps, but not false. It isn't what they do; it is
 > what we do with them and what that costs.  What we do can be done
 > many ways so why should large businesses consider moving away from
 > working solutions to solutions that require retooling?  Again, cost
 > justify it.

I don't think that systems get expensive just because people switch to
XML or SGML and keep on doing what they were doing -- the expense
almost always comes from trying to do something new.  XML and SGML are
flexible enough to piggy-back on top of existing systems where such
systems are available, but people almost always want to do something
different or to try a different way of doing it when they decide to
try XML or SGML, and that's where the cost comes.

To take one example, imagine that you're managing a custom publishing
project.  The standard non-SGML/XML way to do this is to assemble
fairly large components (sections, chapters, or whatever) using
relational databases (where the components are blobs) and/or
document-management systems (where the components are smaller
documents), and you've probably bought an off-the-shelf package that
does this.  If (say) you decide to use XML for the assembly templates
to make those templates system-independent (and reuse them elsewhere
in the system), you have only a relatively small integration problem
on your hands.

But ... and here's the catch ... you realize that with XML it is
possible to customize much further than you already are.  You read
books and articles and find out that you can customize at the phrase
or even the word level, like this (to take a silly example):

  <p>What <choice-group><choice loc="CA">colour</choice>
     <choice loc="US">color</choice></choice-group> is that?</p>

Wow!  That's a lot better than the blunt instrument that you have now, 
so you run ahead an invest a few $100K in an XML-aware DMS that may or 
may not scale to your user base and another $500K for a phase-one
implementation from an XML consulting house, etc., etc., and suddenly
you decide that XML is very expensive.

But you're wrong -- it's not XML that's expensive; it's the kind of
custom publishing that you're trying to do.  It's easy enough to demo
this sort of thing on my notebook with ten sample documents, a browser
and a couple of Perl scripts, but it turns out to be very hard and
expensive to implement in a high-volume, high-performance environment.
That's OK if you really needed that configurability, but if you
didn't, then it was either your inexperience or gullibility that cost
the money, not XML.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 20:26:04 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:44 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90B5@sohos002.ied-support.net>
Message-ID: <Pine.GSU.4.10.9911261224300.395-100000@netcom9.netcom.com>

On Fri, 26 Nov 1999, Mark Birbeck wrote:
> I sort of agree. I think that this is where XSL-FO will come in. XML
> will first be transformed to device-independent layout, and then that
> will be transformed to HTML/XHTML for the Web, WML for the mobile phone
> (for now), PostScript for print, Director for CD-ROM publications, FDML
> (Fridge Door Mark-up Language) for showing on the front of your fridge
> and BOEML (Back Of Envelope Mark-up Language) for developing radical
> ideas.

You forgot SMML (Small Margin Markup Language, not to be confused with
SML) for marking up important mathematical theorems.



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



From schnitz at overflow.de  Fri Nov 26 21:14:37 1999
From: schnitz at overflow.de (Sebastian Schnitzenbaumer)
Date: Mon Jun  7 17:17:44 2004
Subject: XML Application Servers
In-Reply-To: <014801bf3845$7e696b00$0b00a8c0@grissom>
Message-ID: <199911262214.XAA03313@server.overflow.de>

> << Our core technology is the transformation of XML into JavaScript.
> 
> Interesting.
> 
> The US Department of Defense is considering a ban on JavaScript and VBScript
> (due to hacking), so an XML > HTML transformation would be more appealing to
> DoD webmasters.

True. But the idea of transforming one thing only into another thing 
would be the same as HTML 4's one-size-fits-all strategy. An 
interesting idea is to develop a presentational XML grammar that is 
powerful enough to express the unified functionality of, lets say,  
XHTML, SMIL and WML. The pure XML on the server would be 
transformed into that Super-XHTML, and from Super-XHTML into 
various other presentational markup languages based on the 
client's capabilities. The DoD webmasters would automatically see 
everything in plain XHTML, where cgi's (perhaps on a proxy server) 
would mimik the functionality with round-trips to the server, while 
JavaScript-enabled browsers get the same functionality but 
completely client-side, which is similar to mobile phones who work 
with the notion of a stack of cards in WML (multiple screen pages 
inside a single document).

Regards,

Sebastian


---
Stack Overflow AG
Phone: +49-89-767363-70

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



From uche.ogbuji at fourthought.com  Fri Nov 26 21:35:24 1999
From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com)
Date: Mon Jun  7 17:17:44 2004
Subject: New 4Suite mailing list
Message-ID: <199911262135.OAA02296@localhost.localdomain>

There is now a mailing list for 4Suite (http://FourThought.com/4Suite).  To 
subscribe or for list archives, please visit

http://lists.fourthought.com/mailman/listinfo/4suite


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Fri Nov 26 22:41:29 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:44 2004
Subject: [SML] Re: SML ?!?
References: <B1C8643B3AB0D21180250000C0B179CD05B666@JUPITER>
 <383E6E75.B77F776E@vscht.cz> <006f01bf3829$d9c45300$96d88dce@sagus.com>
 <00c001bf382d$c83df290$eb020a0a@bowstreet.com>
Message-ID: <006401bf385f$77a7d6c0$5df5c13f@PaulTchistopolskii>



> > See http://www.xml.com/pub/1999/11/sml/index.html for an article
> describing
> > the SML idea and the controversy surrounding it.
> 
> I noted with interest (and disagreement) the technical arguments against
> attributes.
> 
> If XML is used for representing tree structures or property/value pairs,
> then, yes, attributes can give way to child elements.
> 
> But if XML is used for *markup*, attributes make sense and should not be
> replaced by child elements.
> (I have made this point whenever attribute vs element discussions have
> arisen).

What if actualy there is a third way? I mean :

"XML is used for markup, where every 'marked' element  is in fact an 'object' "

 > Why? Because in *markup* there is a distinction between content and markup.
> The character data content of an element is content. The value of an
> attribute is markup. Attributes, like other markup, provide information in
> addition to the textual content.

I agree - this is very consistent. It is also consistent to say : 

"we should have separate address space for code and separate 
address space for data even both are just bytes".

I had a chance to write some assembly code  for both 
architectures ( for the architectures where  code should live 
separately from the data and for the architectures where 
both code and data are considered to be 'the same' ).

I think anybody who had a comparable experience would 
agree that 'mixed'  approach is *much* more convinient
for the user. Not talking about efficiency,  but only what 
is less limiting.
 
> For example, a person thinking how to express the fact that Max is a dog
> that is black might use:
> 
> <dog>
>     <name>Max</name>
>     <colour>black</colour>
> </dog>
> 
> However, a person wanting to markup the text "Max" indicating that he is a
> black dog couldn't do the above. They might, instead, use:
> 
> <dog colour="black">Max</dog>

What both things do - they are saying that in this place 
of the document we actulay have an object Dog with some 
properties.  

To me - the only advantage of  attrubutes-based notation is that 
is gives some information about what attribute of that 
object is 'more important'.  Very misleading thing in general.
It's up to stylesheet to decide *what* is important. 
( With <comment> </comment> there is also a  way to 
give a priorities to comments ;-) Isn't it nice and 
consistent, to consider comments to be a part of 
XML content ? )

<aside>

With attributes shorthands I see a design pattern here, 
very similiar to descision that have been done with 
XML / SAX  design. 

A couple of days ago I enjoyed the result of that  "we 
know better *what* is XML document so we know that 
developer will *not* need the information about ignorable 
whitespace outside the root element".... ( not talking about 
the comments e t.c. ). Actualy  existing SAX/XML point 
of view is very contradicting. If comments are of our 
interest why ignoreable whitespace outside the root 
document  is *not* of our interest? Why <?xml header 
is not of our interest ? If we are concerned only about the 
'meanful content' or 'semantics' -  what is the difference 
between comments and ignoreable whitespace ??? 
Both are not the content, right ? ;-)

Not talking about the XML itself, existing  XML *framework*  
is inconsistent. A bit. But sometimes it hirts. 

</aside>
 
> So if XML is being used for marking up existing textual content, attributes
> have a definite place.

Yes, attributes is a nice shorthand, like many other kludges that 
XML has. I think most of kludges come from SGML world, where 
people was used to prepare most of the documents manually, 
it's why we have <!-- kludge, CDATA kludge, weak macroprocessor
( kludges-based ) and weak ( useless in the real life, when it 
comes to ... for example XSL FO ;-)  DTD-based validation.

Because XML has different ( wider ) domain area than SGML has, 
dropping all those legacy kludges may be reasonable, because 
it could bye *much* more simplified and layered *framework* than
it could be done on top of XML.

There is a design pattern in every part of  every 'standard'
that  is built on top of XML and I think that pattern is a 
death end. Of course, it would not die, but  from 
technical-political standpoint, XML v 2 is just an issue of time 
to me. XML is hyped, but it also has a *perfect* concept that 
allows you to re-think how your dataflows could be managed 
in some 'different' , realy componentized way.

That concept does not equals to  XML.

If *not* talking about the political issues, from technical 
standpoint SML gives you comparable 'technical' benefits.  

If making agreement on SML  :

-  elements and PCDATA

-  no kludges:
        use <comment> </comment>
        no macroprocessing
        no attributes
        no weak DTD's 

we'l have .... well ... it's 

Some mix of elements and PCDATA.

( with maybe <BR/> shorthand. The
only stuff I like... even it causes so many 
problems with <BR></BR> .... Maybe 
it should be dropped also ). 

Maybe it should be also  UTF-something 
based and there are some questions about 
whitespace. 

And it is still XML!  

Anyway - such SML could be the perfect
level 0 of that hypotetical 'killer' framework.

Most of the existing ( too-bloated-to-fit-into-cell-phone ) 
layers  could be replaced and there could be some 
amazing software built on top of it.

XML-based XT would not fit easily into the cell phone
SML-based XT would fit  with no problem.

XML-based PDOM on top of SQL could not be 
created in a reasonable time.
SML-based PDOM on top of SQL is doable.

Not talking about XT,  embeded into any 
program, like regular expressions are
e t.c. 

I think kludges should die. After 7 years of 
perl development ( full of kludges, you know ) 
I know for sure that it is a death end ( like 
PL/1 was )

If the thing is 'not-easy-embeddable'  - it's bloated,
It's not a nice  ground. I'm not using perl anymore - 
only for some temporary hacks. After 7 years ...
It's so hard for me to explain why perl is bad, 
because people are returning me the same 
words I told them for 7 years ;-) It's 
also very  hard for me to explain why XML 
is not perfect, because for last year I was an
XML evangelist ;-)

As far as I remember  from the history of  FOP, 
at some point you have switched from perl to 
Python ( it think it was because there was no 
JPython at that point  ;-) ).

It was very reasonable step from my point of 
view.  ;-)

Rgds.Paul.




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



From KenNorth at email.msn.com  Fri Nov 26 23:38:41 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:44 2004
Subject: XML Application Servers
References: <8DCB90532FF7D211B34400805FD48853AFE95F@SENMAIL3>
Message-ID: <006601bf3867$a8cc2000$0b00a8c0@grissom>

> I am interested in the different ways people doing this have managed to
> integrated this technology with the XML technologies.


"Anatomy of an XML Server" by Bob Bickel, one of the architects of Bluestone
XML-Server:
http://www.webtechniques.com/archives/1999/06/bickel/



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 01:52:30 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:44 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <199911261240.MAA24954@nag.co.uk>
Message-ID: <001301bf387a$6880cba0$099918d1@docuverse1>

>Name ::= NameStart (NameChar)*
>NameStart ::= [a-zA-Z] | '_' | ':'
>NameChar ::= NameStart | [0-9] | '.' | '-'
>
>Given all the work that's currently going on to 
>internationalise the web (and computing in general)
>and remove historic English bias, is it really
>politically or culturally acceptable to restrict 
>element names to the English alphabet? If SML is
>only for English you could restrict the character
>data to be ascii as well to save on processing utf8
>characters.  If it isn't only for English then the
>above would presumably be one of many SML, SML-EN,
>and you would expect to see similar variants allowing
>element names in French or Russian, or Japanese?

Given that most of the popular programming languages
have similar limitations regarding identifier names,
I think the, so called, English bias is acceptable.

Furthermore, XML is supposed to be easily readable
by human eye.  Question is, is it just the creator's
eye or anyone's eye.  An XML document created by
Chinese engineers will not be very readable to English
engineers if names are in Chinese.  This will make it
difficult for foreign companies to communicate with
Chinese e-commerce businesses.

The reverse is not true.  I dare say that every engineer
in the world knows enough English to understand English
tag names and attributes names with the aid of readily
available dictionary.  Ask any foreign engineers if they
use names in English or their own language when they name
C or C++ identifiers.  Ask any foreign engineers if they
did not have some English training even before College.

Internationalization is also less of a problem than you
think.  Translating English name to foreign words usually
results in a weird words.  Just ask any foreigner with
foreign version of Windows if the menu commands made good
sense to them when they first started using it.  The fact
is that when a person learns how to use computers in non-
English speaking countries, they have to learn a whole new
set of words consisting of old or uncommon words overloaded
with new meanings.

Also, we are going to have a big problem with schema
differences in the future and I would rather not have
foreign language variations of common tags like <name> and
<address> in the pot as well.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 01:52:33 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:44 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <3.0.6.32.19991126092833.00a05e80@gpo.iol.ie>
Message-ID: <001201bf387a$676c9c80$099918d1@docuverse1>

Sean,

>>data ::= (element | CharData | CharCode)*
>
>So a resource consisting of just character data
>is a valid SML instance?

Yes.

>So SML will not be a "subset of XML"?

SML is a subset in the sense that it meets the
external parsed entity requirements, XML fragments
in other words.

>If I have understood you right then this
>blows it for me I'm afraid:-(

Sorry about that.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 02:04:10 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <001601bf387c$0a812840$099918d1@docuverse1>

I believe it is now time to address the question of
whether Attribute should be supported in SML or not.

I think it is clear that attributes are needed under
the 'tradition' view of markup where all character
data is considered to be 'content'.  I think this
view is just as dangerous and restricting as the
'sacred main document structure' view.

Unless there are compelling needs for attributes
beyond the need to preserve 'sacred content', I
believe attributes should be removed.  So here is
the question I put to you:

  "Why should attributes be supported in SML?"

In order to keep this thread to a manageable
level of noise, please limit yourself one reason
per message to sub-threads should be created if
necessary to focus on one particular reason per
thread.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 03:01:53 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
References: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <01c501bf3843$b4404b60$eb020a0a@bowstreet.com>

> I think it is clear that attributes are needed under
> the 'tradition' view of markup where all character
> data is considered to be 'content'.  I think this
> view is just as dangerous and restricting as the
> 'sacred main document structure' view.

Don't get me wrong. I have no problem with dropping attributes in SML. What
I was objecting to in the XML.COM article was the view that attributes were
a mistake in SGML in the first place.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 03:24:26 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <01c501bf3843$b4404b60$eb020a0a@bowstreet.com>
Message-ID: <000101bf3887$3e559600$099918d1@docuverse1>

>> I think it is clear that attributes are needed under
>> the 'tradition' view of markup where all character
>> data is considered to be 'content'.  I think this
>> view is just as dangerous and restricting as the
>> 'sacred main document structure' view.
>
>Don't get me wrong. I have no problem with dropping attributes 
>in SML. What
>I was objecting to in the XML.COM article was the view that 
>attributes were
>a mistake in SGML in the first place.

Heh.  Thanks for the 'smackeroo', James.  That will teach me
to skipover a paragraph or two. <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 04:12:14 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
References: <000101bf3887$3e559600$099918d1@docuverse1>
Message-ID: <023a01bf388d$95aa66a0$eb020a0a@bowstreet.com>

> Heh.  Thanks for the 'smackeroo', James.  That will teach me
> to skipover a paragraph or two. <g>

Just be warned (and this applies to all xml-dev denizens): I may be
unusually (or is that usually?) argumentative for the next week as I'm madly
trying to get ready to move over to the US in one weeks time and I'm going
crazy.

James

PS SML should be internationalized! (whoops, there I go)
PPS I do like dropping attributes: it will decrease by an order of magnitude
the amount of time it takes to design a DTD/schema by committee :-)


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



From liamquin at interlog.com  Sat Nov 27 04:37:13 1999
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Re: SML ?!?
In-Reply-To: <00c001bf382d$c83df290$eb020a0a@bowstreet.com>
Message-ID: <Pine.BSI.3.96r.991126232709.4417A-100000@shell1.interlog.com>

On Fri, 26 Nov 1999, James Tauber wrote:
[...]
> Why? Because in *markup* there is a distinction between content and markup.

That I agere with.

> The character data content of an element is content. The value of an
> attribute is markup.

> Attributes, like other markup, provide information in
That is subjective, and I don't agree.
Nowhere is it stated in the XML spec that this must be so.

It is a useful convention that some people choose to follow.  One reason
I often advise people to follow it is that attribuets are syntactically
impoverished in XML, as in SGML, and can't contain sub-elements.  As
a result,
    <document title="pictuers ofmy dog"> ... </document>
sort of works, but
    <document title="e = m c <sup>2</sup"> .. </document>
fails miserably (is not even well-formed XML, and certainly does not
"mean" what one might hope).

The Text Encoding Initiative P3 Guidelines provide other ways of
representing the difference between a reviewer's comments and original
content, and also of representng uncertainty in the reading of a text
that one is transcribing.

Restricting editorial comment to attributes seems to me to give it
some pretty severe limits.  What if you want to add a footnote with
a cross reference?

I agree that attributes can be useful, and that there are several
sets of conventions when make a distinction between "content" and
"markup" in some way that may consider attributes to be part of
markup.

However, let's not make the mistake of saying that that's the only
way to use XML.

For my own part, I'd be giernally be willing to accept this:
    <e>
      <xml:atts>
	<att>value</att>
	<att>value</att>
      </xml:atts>
      content
    </e>
(just as an example, not intended as a specific proposal) which retains
the distinction ebtween attributes and content, but does not need the
extra syntactic form.  But I'm happy with attributes too.

I think attribtues actually fall into the category of things that if
the average writer of an HTML browser can understand, they must be
pertty simple :-) :-) :-)

-- 
Liam Quin, Barefoot Computing, Toronto;  The barefoot agitator
l i a m q u i n     at    i n t e r l o g    dot   c o m
Ankh on irc.sorcery.net, http://www.valinor.sorcery.net/~liam/


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



From jlapp at webmethods.com  Sat Nov 27 05:05:53 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <199911261240.MAA24954@nag.co.uk>
Message-ID: <199911270505.VAA08984@harrier.prod.itd.earthlink.net>

I agree with David.  If SML doesn't support the full gamut of encodings, it's useless to us.  I'm very much a supporter of a simplified XML, but our business is international.  It's one thing to promote a simplified syntax for ecommerce and quite another to promote a standard (spoken) language.  (BTW, I'm not sure any business would buy that convert-to/from-English argument.)

And let's please do dump attributes.  We can save the world countless hours of time wasted in philosophical discussion and in trying (and largely failing) to produce technologies that make first class citizens of both attribute values and element content.  It would be nice to make the issue moot for SML.

Also, your XML won't quite be a subset unless you disallow ']]>' from content.  Don't know why this was ever disallowed in XML; it should only have been disallowed in CDATA sections.

At 12:40 PM 11/26/1999 +0000, David Carlisle wrote:
>
>
>Name ::= NameStart (NameChar)*
>NameStart ::= [a-zA-Z] | '_' | ':'
>NameChar ::= NameStart | [0-9] | '.' | '-'
>
>Given all the work that's currently going on to internationalise the web
>(and computing in general) and remove historic English bias, is it
>really politically or culturally acceptable to restrict element names to
>the English alphabet? If SML is only for English you could restrict the
>character data to be ascii as well to save on processing utf8
>characters.  If it isn't only for English then the above would
>presumably be one of many SML, SML-EN, and you would expect to see
>similar variants allowing element names in French or Russian, or
>Japanese?
>
>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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 05:26:39 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Re: SML ?!?
References: <Pine.BSI.3.96r.991126232709.4417A-100000@shell1.interlog.com>
Message-ID: <026101bf3897$fabd2460$eb020a0a@bowstreet.com>

> > The character data content of an element is content. The value of an
> > attribute is markup.
>
> > Attributes, like other markup, provide information in
> That is subjective, and I don't agree.

Which bit is subjective? The fact that attributes are markup? No, the spec
indirectly says that.

> I agree that attributes can be useful, and that there are several
> sets of conventions when make a distinction between "content" and
> "markup" in some way that may consider attributes to be part of
> markup.

Attributes are markup and not content in the sense that those words are
using in the XML spec. Whether the distinction between markup and content in
the sense used in the spec is useful semantically is the issue.

>
> However, let's not make the mistake of saying that that's the only
> way to use XML.

I never said that's the only way of using XML. What I said was that it is
*a* way of using XML and so attributes do have some use (for those people
that adopt conventions that make the content/markup distinction)

It is not clear cut, as Robin's post demonstrates, but I have always seen
somewhat of a continuum where property/value data stuff (at one end) is
completely blurred and document markup stuff (at  the other end) is clearer
(although not complete clear).

Of course, content almost always has its own structure in some non-XML
notation. And as I argued at SGML/XML Asia Pacific 1998, the distinction
between what you leave as content and what you make markup is very
application-specific.

<dog>Max</dog>

my be more usefully marked up as

<dog>
  <word>
    <letter name="m" capitalized="yes"/>
    <letter name="a"/>
    <letter name="x"/>
  </word>
</dog>

for some applications.

James

PS Boy am I going to be glad when Joe Stephenson gets back! :-)




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 06:05:53 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Preliminary EBNF for SML
Message-ID: <004501bf38a0$f30c84f0$42f96d8c@NT.JELLIFFE.COM.AU>

 
From: Don Park <donpark@docuverse.com> 

 >The reverse is not true.  I dare say that every engineer
>in the world knows enough English to understand English
>tag names and attributes names with the aid of readily
>available dictionary.  Ask any foreign engineers if they
>use names in English or their own language when they name
>C or C++ identifiers.  Ask any foreign engineers if they
>did not have some English training even before College.

You would be entirely mistaken in this.  Engineers in Africa 
may have  French as their second language; engineers from 
ex-Eastern Bloc countries will have Russian as their second language.
Engineers in China will have Mandarin as their second 
language.  And the skills of reading and writing are different:
many people can recognise English words in context but 
cannot recall them.  Asking professional people in America 
if they  speak English hardly proves anything.

And are you saying that SML is a language that only 
engineers should read and write?

>Internationalization is also less of a problem than you
>think. 

This is utterly bogus.  Every different language and domain
area has different problems.   

> Translating English name to foreign words usually
>results in a weird words.  Just ask any foreigner with
>foreign version of Windows if the menu commands made good
>sense to them when they first started using it.  The fact
>is that when a person learns how to use computers in non-
>English speaking countries, they have to learn a whole new
>set of words consisting of old or uncommon words overloaded
>with new meanings.

So we should perpetuate this and make it worse?  And it is not
correct to suggest that a foreign version of Windows has menu
items that are simply the English words transliterated or directly
translated. Of course there is a set of meanings of words to learn;
but why should their be a foreign vocabulary as well? 

>Also, we are going to have a big problem with schema
>differences in the future and I would rather not have
>foreign language variations of common tags like <name> and
><address> in the pot as well.

Is this any difference from saying "I don't care how difficult it
is for losers who find English difficult, as long as it is convenient 
for me?" 

Furthermore, there are many terms that do not have exact
translations.  What is the English equivalent for the Japanese
address unit "cho"?   I helped an accountant at my work
try to develop standard English translations for payroll
deduction terms here in Taiwan, and there are many which
simply are not found in English: without a really complicated
explaination with multiple English words there is no way
to give the same markup: looking up words in a dictionary
is not a productive use of time.  Such systems would require
an extra layer of software to provide UI help, in which case
the advantage of "simplicity" is lost.

I agree that it is good to have standard
terms for common things, and that English is the best choice
at the moment, but unfortunately not every word exists in 
English and most people in the world do not speak it or read
it.

Why reduce markup to mere nmemonics rather than be able
to use names?   

One reason for allowing native language markup is that it
can enfrachanchise the great proportion of the world who
are literate but not in English.  The goal of markup 
systems should not be to make life easier for programmers,
but to reduce the requirement for extraneous-to-the-task skills 
as markup is used instead. These extraneous skills should include
both programming and English-knowledge.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 06:16:40 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>

 
From: Don Park <donpark@docuverse.com> 

>I believe it is now time to address the question of
>whether Attribute should be supported in SML or not.
 
Because it is convenient for programming. 

It seems that most XML programs are written so that
the elements "push" programs but attributes values
are "pulled" in.  So the programmer does not need
to concern themselves with attributes that are redundant
to their task.  To make everything an element would 
reduce the choices available to a programmer.

Are you talking about syntax or labelling here?  You can
see that some people say "lets remove attributes and
have '<sml:attribute>' instead".  Others say "lets
remove comments and have 'comment' instead". This is
not a simplification at all: the handling of these
has to be handled by subsequent layers (or, worst, by
the programmer explicitly: will we have to put in
    comment { display: none }
    sml:attribute {display: none}
into every CSS stylesheet?   

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 06:34:29 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:45 2004
Subject: #2 Re: [SML] Whether to support Attribute or not?
Message-ID: <007501bf38a4$f7a745f0$42f96d8c@NT.JELLIFFE.COM.AU>

 From: Don Park <donpark@docuverse.com> 

>I believe it is now time to address the question of
>whether Attribute should be supported in SML or not.
 
Since you are not asking for use-cases, the only logic
driving SML is reductionism. The result can only
be a language with 1 encoding and 1 tag and the 
minimum repertoire for names.

SML = (data | "<" ASCII* ">" SML "<" ASCII* ">"  )*

Given this, discussion seems utterly futile.

If people are serious, they should first establish some use-cases
of where XML fails.  This will also bring out the ramifications
of simplicification.

In any case, it seems to me that reductionism and anti-reductionism
are often character traits rather than technical positions capable
of being debated. A reductionist will say "if attributes do not mean
something they mean nothing" while an anti-reductionist might 
respond "it is a DTD/Schema function to allocate the particular
roles attributes/elements according to the methodology of the
DTD/schema designer: it is a source of richness for there to be
a syntactic disrinction which is methodogical neutral and available."


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 07:04:47 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
References: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <383F802D.E9F85303@cs.ucsd.edu>



Don Park wrote:
> 
> I believe it is now time to address the question of
> whether Attribute should be supported in SML or not.
>

I am not a frequent participant here, but I am opposed 
to the use of attributes in the XML as it is happening 
right now. What I don't like is the way query languages 
for XML suffer because of the attributes.

Attributes require a special syntax in the XML query 
languages, just like in XML itself. Instead
of writing OQL-ish path expressions like:
	homes.home.id

you will have to write:
	<homes> <home id=_ /> </homes> in XML-QL or similar
languages. XQL also does not treat attributes and element
equally.

If you don't know whether the object you are picking is an
attribute or an element, you will have to write a disjunction.
There could also be a case when an element has an attribute
and a subelement with the same name, you might have to
guard against such case. I.e. things get messy fast.

So I think if attributes are out, a lot of XML tools, including 
query processors will get simpler. Also there will be less 
opportunity for the users to screw up when using these tools.

Pavel Velikhov
pvelikho@cs.ucsd.edu
http://www.db.ucsd.edu

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 07:19:59 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <009001bf38ab$53eb8410$42f96d8c@NT.JELLIFFE.COM.AU>

 
From: Pavel Velikhov <pvelikho@cs.ucsd.edu>
 
>If you don't know whether the object you are picking is an
>attribute or an element, you will have to write a disjunction.
 
When don't you know whether an object you are picking is an 
attribute or an element?  

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 08:05:01 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Internationalization. (Preliminary EBNF for SML)
References: <004501bf38a0$f30c84f0$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <011801bf38ae$43018020$5df5c13f@PaulTchistopolskii>


I agree with Rick that  this area is actualy 
*very* tricky.

Being Russian engeneer I would say that 
restricting element names to English in SML 
is very reasonable.

But unfortunately, analyzing the ( 5+ years ) 
experience of multiple 'Cyrillizations'  ( and 
some other localizations) ( a *lot* of )  - I should 
say that for end-user it  *is* critical to be able 
to use non-English names for elements and 
yes - it could be *very* important.

Even the translations of   ( for example )
Windows menus to Russian are realy weired
( not because they were done by bad translators.
they were done by *perfect* translators )
and for engeneer it is realy *much* easier to use 
not-localized version than localized,  but 
majority of 'advanced users'  including 
some engeneers *do* prefer to name their 
files and folders in Russian. SML is not a 
programming  language. It is a framework....

Conclusion.  I think the best approach could 
be: 

1. Only English *elements* ( but 'any'  content)
in SML version 1.  

2.  'Any'  encoding  anywhere in SML version 2.

What is 'any' - it's a big question and 'any' in 
(1) could be not the same as 'any' in (2).

I think any reasonable design should postpone 
some descisions until the basics are tested 
in the real life. Postponing some descisions  
to SML version 2 may be  reasonable, and 
multilingual elements look like such a thing.

Rgds.Paul.

----- Original Message ----- 
From: Rick Jelliffe <ricko@allette.com.au>

> 
> From: Don Park <donpark@docuverse.com> 
> 
>  >The reverse is not true.  I dare say that every engineer
> >in the world knows enough English to understand English
> >tag names and attributes names with the aid of readily
> >available dictionary.  Ask any foreign engineers if they
> >use names in English or their own language when they name
> >C or C++ identifiers.  Ask any foreign engineers if they
> >did not have some English training even before College.
> 
> You would be entirely mistaken in this.  Engineers in Africa 
> may have  French as their second language; engineers from 
> ex-Eastern Bloc countries will have Russian as their second language.
> Engineers in China will have Mandarin as their second 
> language.  And the skills of reading and writing are different:
> many people can recognise English words in context but 
> cannot recall them.  Asking professional people in America 
> if they  speak English hardly proves anything.
> 
> And are you saying that SML is a language that only 
> engineers should read and write?
> 
> >Internationalization is also less of a problem than you
> >think. 
> 
> This is utterly bogus.  Every different language and domain
> area has different problems.   
> 
> > Translating English name to foreign words usually
> >results in a weird words.  Just ask any foreigner with
> >foreign version of Windows if the menu commands made good
> >sense to them when they first started using it.  The fact
> >is that when a person learns how to use computers in non-
> >English speaking countries, they have to learn a whole new
> >set of words consisting of old or uncommon words overloaded
> >with new meanings.
> 
> So we should perpetuate this and make it worse?  And it is not
> correct to suggest that a foreign version of Windows has menu
> items that are simply the English words transliterated or directly
> translated. Of course there is a set of meanings of words to learn;
> but why should their be a foreign vocabulary as well? 
> 
> >Also, we are going to have a big problem with schema
> >differences in the future and I would rather not have
> >foreign language variations of common tags like <name> and
> ><address> in the pot as well.
> 
> Is this any difference from saying "I don't care how difficult it
> is for losers who find English difficult, as long as it is convenient 
> for me?" 
> 
> Furthermore, there are many terms that do not have exact
> translations.  What is the English equivalent for the Japanese
> address unit "cho"?   I helped an accountant at my work
> try to develop standard English translations for payroll
> deduction terms here in Taiwan, and there are many which
> simply are not found in English: without a really complicated
> explaination with multiple English words there is no way
> to give the same markup: looking up words in a dictionary
> is not a productive use of time.  Such systems would require
> an extra layer of software to provide UI help, in which case
> the advantage of "simplicity" is lost.
> 
> I agree that it is good to have standard
> terms for common things, and that English is the best choice
> at the moment, but unfortunately not every word exists in 
> English and most people in the world do not speak it or read
> it.
> 
> Why reduce markup to mere nmemonics rather than be able
> to use names?   
> 
> One reason for allowing native language markup is that it
> can enfrachanchise the great proportion of the world who
> are literate but not in English.  The goal of markup 
> systems should not be to make life easier for programmers,
> but to reduce the requirement for extraneous-to-the-task skills 
> as markup is used instead. These extraneous skills should include
> both programming and English-knowledge.
> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 08:36:37 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Whether to support Attribute or not?
References: <009001bf38ab$53eb8410$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <383F9599.A8AABAAE@cs.ucsd.edu>



Rick Jelliffe wrote:
> 
> 
> From: Pavel Velikhov <pvelikho@cs.ucsd.edu>
> 
> >If you don't know whether the object you are picking is an
> >attribute or an element, you will have to write a disjunction.
> 
> When don't you know whether an object you are picking is an
> attribute or an element?
> 
> Rick Jelliffe

When you are querying a collection that does not have a DTD for
example. You may know that homes have an id, but you don't know
whether the id is an attribute or a element. Another case is a 
relational->XML wrapper, it export relational attributes as
XML attributes, but might as well export them as elements.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 09:07:58 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <001201bf387a$676c9c80$099918d1@docuverse1>
References: <3.0.6.32.19991126092833.00a05e80@gpo.iol.ie>
Message-ID: <3.0.6.32.19991127084045.00a0c100@gpo.iol.ie>

[Don Park]
>
>SML is a subset in the sense that it meets the
>external parsed entity requirements, XML fragments
>in other words.
>

As a consequence, no XML 1.0 parser can be used
out-of-the box to parse SML. Ugh!

I think this one crosses the rubicon. I have
high hopes for SML. *Please* make is truly
a subset of XML 1.0.

>>If I have understood you right then this
>>blows it for me I'm afraid:-(
>
>Sorry about that.
>
Likewise.

regards,




<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 09:08:17 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:45 2004
Subject: [SML] Preliminary EBNF for SML
Message-ID: <3.0.6.32.19991127084922.009b5dd0@gpo.iol.ie>

[Don Park]
>
>SML is a subset in the sense that it meets the
>external parsed entity requirements, XML fragments
>in other words.
>

An SML document will not be an XML 1.0 document.
No XML 1.0 parser can be used out-of-the box to
parse SML. Your use of "subset" here is
misleading.

I think this one crosses the rubicon. I have
high hopes for SML. *Please* make is truly
a subset of XML 1.0.

>>If I have understood you right then this
>>blows it for me I'm afraid:-(
>
>Sorry about that.
>
Likewise. Sigh. My first gut reaction is
to say "hey, I'll find some like-minded people
and do it myself and call it NBML - No Brainer
Markup Language - or something."  But this is the
rocky road to a faction fight. I don't
want to go there. I live close to one of those
that has been going  on for 300 years so
and I don't need another one.

*Please make SML truly a subset of XML 1.0*

regards,




<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 09:37:40 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:46 2004
Subject: [SML] Comments ( Whether to support Attribute or not? )
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <019f01bf38bb$4cd301c0$5df5c13f@PaulTchistopolskii>


From: Rick Jelliffe <ricko@allette.com.au>

> From: Don Park <donpark@docuverse.com> 
> 
> >I believe it is now time to address the question of
> >whether Attribute should be supported in SML or not.
>  
> Because it is convenient for programming. 

I think it is not. 

It may be convinent for writing the document, but it 
introduces especial syntax for *processing* the 
document.

It's similiar to ... If we require in, say, C++  to use 

a   = B;        // B is variable
a $= B;        // B is constant

> It seems that most XML programs are written so that
> the elements "push" programs but attributes values
> are "pulled" in.  So the programmer does not need
> to concern themselves with attributes that are redundant
> to their task.  To make everything an element would 
> reduce the choices available to a programmer.

I don't understand. I simply don't understand. 

Well ...  maybe you are saying  that removing the kludge 
from a $= B redices some choices ... Maybe it does. 
It's the issue of taste, I think. 

However, it's very common thing when something 
designed to be a constant  becomes a variable 
( and back ). I already experienced the same 
things with attributes and elements.
 
> Are you talking about syntax or labelling here?  You can
> see that some people say "lets remove attributes and
> have '<sml:attribute>' instead".

I missed the original letter,  suggesting such a thing....

I don't think it is reasonable. I think it's better to drop 
attributes, even they are very handy kludge - I think 
the cost is not worth it ( it was worth it in SGML, I think ).

>   Others say "lets
> remove comments and have 'comment' instead". This is
> not a simplification at all: the handling of these
> has to be handled by subsequent layers 

1. It *is* some simplification.
2. It makes the step forward.

Comments  are considered to be the part of the 
content.

Is it strong suggestion? Yes. Is it for sure wrong? 

I don't think so  - so  I'm writing a bit more on it, 
sorry if it would somtimes be not exactly about the 
comments, but I hope it is.
 
Actualy, Java already did the half-step in that direction, with 
javadoc. People enjoyed comments to become *more* 
than some verbal junk.  

Current situation with comments in XML ( and XML APIs) 
is very strange. On one hand they are part of the content 
( DOM works with them ) on another hand they are not
( SAX v 1.0 does not ). Inconsistensy. Isn't it ?
    
> (or, worst, by
> the programmer explicitly: will we have to put in
>     comment { display: none }
>     sml:attribute {display: none}
> into every CSS stylesheet?   

Unfortunately, for some reason I like XSL FO 
more than CSS, but I actualy see no big 
problem placing  

comment { display: none }

into every stylesheet. I am *already*  required 
to place many things into XSLT stylesheets, 
and also I  place #include <stdio.h> and 
use strict. It does not hirt me. 

But.

Maybe it would be handy to change 
current behaviour to ( 'what is not declared  - 
is not processed' ).  I mean that most of 
existing XML-related tools are dumping out 
everything they find in XML document if there 
is no command/instruction not to dump it. 

I don't think  it is good. It could be better 
to tune this behaviour with  

default { something }  

( if default is not defined - it is 'none'  ;-)

I don't  like HTML browsers 'silently fixing' 
my HTML, I don't  like compilers  silently 
initializing my variables to 0 and stuff like that.

If it is not decalred  - don't  initialize it. 
If it is not set for being drawn - don't draw it, 
because if you do ( like current HTML 
browsers do ) -  it  gives  the user an  impression 
that everything is fine in the situation when 
everything is *not* ( like it is with initialization 
with 0 ).

Unfortunately, it is a bit not related to the 
comments, but I just had to say that  things 
could be done in a bit different way with 
comments ( so you will have no need to 
write especial rule for comments. Or you 
will need only if you decided to write
default: { something here } ).

Rgds.Paul.




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



From mikew at o3.co.uk  Sat Nov 27 09:50:42 1999
From: mikew at o3.co.uk (Mike Williams)
Date: Mon Jun  7 17:17:46 2004
Subject: XML Application Servers
In-Reply-To: "Didier PH Martin"'s message of "Fri, 26 Nov 1999 07:28:27 -0500"
References: <NBBBJPGDLPIHJGEHAKBAGELGEHAA.martind@netfolder.com>
Message-ID: <m3hfi8z2z9.fsf@picasso.o3.co.uk>


  Didier> We are building something similar to this. However, the XML
  Didier> server checks the client's version and if the server detect that
  Didier> it is an XML server it sends the XML+XSL or XML+CSS to the
  Didier> client. Otherwise the XML document is transformed server side. 

Nice.

  Didier> We also use XML themplates that we call XSP documents.

Any relation to Cocoon's proposed XML Server Pages?  Do your XSP documents
contain any logic, or just layout?  What kind of templating tags (or other
syntax) do you support?

-- 
Mike Williams

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 11:06:00 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:17:46 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
References: <"199911232329888.SM01008"@Unknown> <3.0.2.32.19991126000518.01029584@pop1.sympatico.ca>
Message-ID: <383FBB0C.4FFE4AE4@prescod.net>

Mark Baker wrote:
> 
> At 09:42 AM 11/25/99 +0100, Paul Prescod wrote:
> >Cell phones must increasingly deal with structured information.
> >Therefore cell phones need to deal with XML.
> 
> Agreed, but that doesn't answer the question of "Why XML?".  

Well that wasn't so much the question that was asked...rev-bob is
obsessed with people who want to read books and entire websites on their
palmtops. I don't see that as the primary target market for XML on
plamtops and cell phones.

> What if I want to send a web page or
> vCard or whatever to another cell phone via IR or Bluetooth, where there's
> no proxy available?  That's where a well-deployed standard matters, and
> *that's* "Why XML?".

Well there is no well-deployed standard for cell-phone to cell-phone
structured information so I think you're still begging the question. Why
not a new standard? And I think that comes down to politics and
sociology, not technology.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"I don't want you to describe to me -- not ever -- what you were doing
to that poor boy to make him sound like that; but if you ever do it
again, please cover his mouth with your hand," Grandmother said.
	-- John Irving, "A Prayer for Owen Meany"

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



From mikew at o3.co.uk  Sat Nov 27 11:21:57 1999
From: mikew at o3.co.uk (Mike Williams)
Date: Mon Jun  7 17:17:46 2004
Subject: XML Application Servers
In-Reply-To: Sebastien Sahuc's message of "Fri, 26 Nov 1999 09:41:58 +0100"
References: <C10B7E3A3AC3D211804E0000B45EDA8435D3BF@mail.imediation.com>
Message-ID: <m3d7swyyl3.fsf@picasso.o3.co.uk>


  Mike> The servlet collects output data in a hash-table.  Then, I (plan to)
  Mike> run a template-processor, which splices this data into existing XML
  Mike> templates, constructing an abstract view of the page.

  Sebastien> Sound similar to the Cocoon publishing framework, expect that
  Sebastien> your control logic is handled by the servlet itself.  This
  Sebastien> latter point should, IMHO, be also XML driven, a la XSP (still
  Sebastien> from Cocoon), 

Hmm. Cocoon is doing very good things, and I took a good look at XSP, but
it didn't quite meet my needs.

  Sebastien> logic description -SHOULD NOT- be hard-coded in servlet but
  Sebastien> rather scripted, and eventually compiled on the fly by the
  Sebastien> server processor.

Well ... the sample XSP code I've seen uses Java as a scripting language,
so it's not as though coding is easier.  Though I do like the idea of
compiling XML into Java code that produces DOM nodes (or SAX events).

Let me explain why I chose to "do my own thing".  

  * XSLT is good for _transforming_ documents, to apply a style.  However,
    it's not so good for assembling document components.  For this, a
    template-like system makes more sense.

  * Similarly, XSLT is good for duplicating markup, ie. which is not so
    good when your markup includes code. If you put code in a XSP
    logic-sheet, then apply this to a number of content documents, it seems
    to me that you'd end up generating a number of pages containing
    identical code.  Messy.

  * Cocoon XSP is not yet a reality, only a work-in-progress.

This is my current world-view:

  * Control *logic* should be in control of what *presentation* method to
    use, and what *content* to include.

  * Templates are a useful way to define data-independent presentation. It
    should be possible to include other templates, allowing a page to be
    built out of re-usable fragments.

  * Templates should be able to display content from different
    sources. They should be *provided with* content to present, rather than
    knowing how to go out and get it.

  * Likewise, it should be possible to display the same content in
    different ways.  So, the content shouldn't (directly) imply the
    presentation mechanism.

I need this flexibility because of the requirements of my current project,
which is a database-backed web application.

  * Dynamically created forms. On some screens, data-entry fields are
    generated dynamically from the database, depending on what's
    appropriate for the object being edited.

  * Context-sensitive help. We need to be able to provide help for each
    screen of our application, describing the forms, fields, links etc on
    that screen.  This includes the dynamic screens mentioned above.  To do
    this, we plan to include help-text in our screen templates, and use
    alternate style-sheets to display either the help or an editable
    screen.

  * User-visible text (labels, help, etc.) cannot be hard-coded in the
    screen templates, but must be but sourced from external
    configuration-files. 

  Sebastien> In our project we don't yet clearly seperate the logic from
  Sebastien> the content, but our approach is the following : We can
  Sebastien> express Business Object behaviour in XML, say simple, actions
  Sebastien> on a EJB are writen in XML and result from such action, 

Interesting ... can you show me an example?

If your logic and content are represented in the same file, can your logic
select alternate content?  For instance, say your logic detects that the
user has entered invalid data, and you wish to re-present the originating
page so they can try again ... how would you do this?

  Sebastien> May you need more information, don't hesitate.

Cheers. I'm very interested in what you're doing.

-- 
Mike Williams

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



From rev-bob at gotc.com  Sat Nov 27 12:37:44 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:46 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <199911270737772.SM01048@Unknown.>

> ** Original Sender: Paul Prescod <paul@prescod.net>
>
> > >Cell phones must increasingly deal with structured information.
> > >Therefore cell phones need to deal with XML.
> > 
> > Agreed, but that doesn't answer the question of "Why XML?".  
> 
> Well that wasn't so much the question that was asked...rev-bob is
> obsessed with people who want to read books and entire websites on their
> palmtops. I don't see that as the primary target market for XML on
> plamtops and cell phones.

So what *do* you see as that primary target market?

I'm not so much obsessed with those folks as I am tenacious regarding my original, very 
basic question.  I just don't grok the reason for a screen on a cellphone; granted, it's a 
neat gadget, but so far it strikes me as an almost-totally *useless* gadget.  I hear a lot of 
hype (especially in the last couple of weeks) about the Wireless Web and how we're all 
going to be surfing through cellphones and palmtops, and it just doesn't "click" for me.  I 
don't *want* to surf on a postage stamp.  Nobody I know wants to do so, either.  
(Okay, one friend of mine surfed a little on a PalmPilot - but he's a bit eccentric 
anyway.)  Why don't we want to do this?  Because we like being able to see a good-
sized chunk of data on a screen.  "Good-sized" is mushy, I know - I'm running my 
monitor at 1024x768 because I like seeing even MORE data, but my friends are 
perfectly happy with 640x480...such is life.

Hence, I'm asking what I thought would be a really simple question - "What am I not 
getting?"  What sort of people *do* want to access the Web through a tiny cellphone 
screen?  So far, I've gotten a lot of theoretical counterpoints, but nothing that really 
addresses the point.  I hate to burst a bubble, but (a) vCards are quite different from full-
blown web pages, and (b) simply stripping banner ads and such from pages won't do 
much to the content size of those pages.  (Well, maybe if you're surfing porn pages or 
hack pages, but not the average page.)  Even my smallest web pages are about 3K or 4K 
- which is about double what I can stand to read on a palm-sized screen.  Therefore, I 
ask - wherefore the wireless web?  Why XML-in-a-cellphone?  It just Doesn't Make 
Sense to me, and all the responses I've gotten are so caught up with "better resolution" 
and "Why are you assuming that a web page has to be a document of substantial size?" 
that they Don't Get It.  (And as for that assumption - because every web page I've ever 
seen IS a document of "substantial size" for this concern; 4K may not sound like much, 
but try reading it on a palmtop or a cellphone.  Point made?)  My objection is not to 
Current Rendering Thresholds - it's to the very concept of trying to read even minimally 
complex thoughts on a screen the size of two postage stamps.  From my viewpoint, a 
web page isn't worth my reading time if it's not either confirming that something has 
been sent (a confirmation page) or at least minimally complex in terms of communicated 
information...in other words, if you don't have something to say, I don't want to hear it.  
Yes, there is some important data which can be communicated in just a few bytes - 
stock quotes and vCards come to mind, and I've already conceded that point.  However, 
general XML support seems more suited to a Whole Ball Of Wax application, and I 
remain unconvinced that palmtops and cellphones qualify.

I have suggested some possible avenues that might get around this visual real estate 
problem - for instance, bypassing the screen idea entirely and using text-to-speech 
rendering, or going outside the current palmtop form factor to something which would 
allow for a larger screen via the clamshell metaphor.  However, the existence of these 
possibilities does not justify XML parsers in current-metaphor devices.  Should a 
cellphone have an XML parser?  As cellphones are currently being built, I see no reason 
for it.  Should a palmtop web browser have an XML parser?  I don't even see who's 
using the palm-browsers currently available; who are these people?

I'm more than willing to admit that I might be missing some key segment of the 
population and utterly not grokking their desires.  Fine; show them to me and I'll know 
they exist.  If I know they exist, I can adjust my content development efforts to take 
them into consideration.  Otherwise, I see no reason to spend time doing that - and since 
I'm primarily a content developer, that's my main concern.  I'm not obsessed with people 
reading Moby Dick on their PalmPilots - I'm obsessed with providing the people who 
visit my site the best content they can see.  If somebody's really using palmtops to see 
the Web, I want them to be able to see what I've got to say - even if only a couple of 
them ever stop by.  If it's all just hype for an unused feature, though, I have better ways 
to spend my time.  Converting my 4DOS batch files into WSH scripts comes to mind....

Oh, to swipe a bone from the SML threads, here's another thing to toss in.  I have a hard 
time visualizing radical internationalization on a tiny screen.  Anglo-centric characters, I 
get.  Asian scripts and Cyrillic...well, those seem a bit out of range.  Again, am I missing 
something?  Call me strange, but I just don't see the pixel density on current palm/cell 
screens being big enough to display a reasonable amount of Kanji data.  Maybe this is an 
argument in favor of a limited-i18n dialect (or subset) of XML for such devices, and 
maybe not - too early to tell right now.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Sat Nov 27 13:22:46 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:46 2004
Subject: XML:  Still Just HypedWebStuff
Message-ID: <199911270822811.SM01048@Unknown.>

At the risk of sounding pretentious, contentious, or even both....

> To take one example, imagine that you're managing a custom publishing
> project.

Not hard to imagine from here; I publish my own zine, and have had to assemble my 
own funky way of managing an ever-growing site singlehandedly with minimal effort.

> The standard non-SGML/XML way to do this is to assemble fairly large components
> (sections, chapters, or whatever) using relational databases (where the components are
> blobs) and/or document-management systems (where the components are smaller
> documents), and you've probably bought an off-the-shelf package that does this.

I'm using document management, if I understand your categories properly.  Specifically, 
each episode of a given column is its own file, and I use a template processor to marry 
these data files to common templates.  This produces a file set that is ready for upload, 
and when a given file is requested, the server does some more processing at that time.  
The template processor (htp) is a small piece of freeware; the server processor is 
available through my ISP's hosting service.  Still, I'm pretty much with you.

> If (say) you decide to use XML for the assembly templates to make those templates
> system-independent (and reuse them elsewhere in the system), you have only a
> relatively small integration problem on your hands.

I might question that "relatively small" bit.  I would find it a large challenge to migrate 
from htp to an XML-based system without losing anything; the big advantage to what 
I've got is that I can set up the htp->XHTML "transformation" <g> to transform valid 
HTML tags into optimized XHTML constructs.  For instance, <center> can become 
<div align="center"> or even <div style="align: center;"> almost as quickly as I can 
envision the transformation.  OTOH, trying to recast the htp data files into full-fledged 
XML fragments would be a much more daunting task.  In fact, it'd be a lot like the 
complexity you go on to describe, except more so:

> But ... and here's the catch ... you realize that with XML it is possible to customize
> much further than you already are.  You read books and articles and find out that you
> can customize at the phrase or even the word level, like this (to take a silly example):
> 
>   <p>What <choice-group><choice loc="CA">colour</choice>
>      <choice loc="US">color</choice></choice-group> is that?</p>

Ultimately, that's a trivial example, and there are better ways (or at least easier ones) to 
do it.  For instance, define your own "color" entity which gets shifted on the fly 
according to location, and this could become:

<p>What &color; is that?</p>

Yes, that has the disadvantage of being something of a hack and requiring a growing 
library of international terms, but IMO, this is more than balanced by the increased 
legibility and decreased footprint of the document.

> Wow!  That's a lot better than the blunt instrument that you have now, 
> so you run ahead an invest a few $100K in an XML-aware DMS that may or 
> may not scale to your user base and another $500K for a phase-one
> implementation from an XML consulting house, etc., etc., and suddenly
> you decide that XML is very expensive.

This is where you make your key logical error.  The database doesn't need to know 
about what's in an element; I currently use Access 97 to handle iHTML script fragments, 
and Access is blissfully ignorant of the uses I'm putting it to.  In fact, if Access was 
bright enough to try making sense of the data I'm storing in there, it could seriously 
screw me over by munging that data.  The hard part of making a library of text granular 
is in going through that library and converting that data accordingly - making the entity 
(or definition) library itself is a snap by comparison.  For instance, if you remember my 
rants about the Q element, setting up the htp definition was only hard because I had to 
manually scout out the support levels for that tag in various browsers.  Implementing the 
definition, on the other hand, requires a lot of tedious work - specifically, poring through 
the various articles and re-marking the quotes accordingly.  There's no shortcut for that, 
no matter what system I use - but since the average user won't notice a big difference, 
there's no real time pressure.  I can make sure that new articles are marked properly as 
they come in, spread the archive re-marking task out over time (since the archives don't 
get a lot of hits), and the load becomes easier.

> But you're wrong -- it's not XML that's expensive; it's the kind of
> custom publishing that you're trying to do.

And I say that you're still half-wrong - it's not that kind of custom publishing that's 
expensive, but the way you're going about it.  Your complication requires no change of 
software, but it does incur a new burden of tedious re-marking of old data.  Spread that 
out a bit (because after all, unchanged documents are not unusable - they're just not 
optimal yet, and they're still the same documents you had up pre-change) and that 
burden becomes more of an inconvenience.  If I were to discipline myself to read 
through twenty source documents a day, I'd be done with my re-marking in a couple of 
weeks.  Five documents a day, and it's two months - which still isn't that bad.

> It's easy enough to demo this sort of thing on my notebook with ten sample
> documents, a browser and a couple of Perl scripts, but it turns out to be very hard
> and expensive to implement in a high-volume, high-performance environment.

And I say, not necessarily.  Take the lexical transformation above - wire the list of terms 
up to a grep bot, and it doesn't much matter whether you're handling ten documents or 
ten thousand.  (Especially with modern CPU speeds!)  After a template change, I can 
generate my 570-page site in a couple of minutes at most.  Sure, the upload will take a 
half-hour to 45 minutes, but I can set that to run while I'm asleep or at work, and that's 
not really a function of my development environment.  (Case in point - the other day, I 
changed the XHTML definition set to conform to the new Working Draft's !DOCTYPE 
and namespace revisions.  The generation took a couple of minutes, and the files went 
up last night as a weekly update.  The transfer broke down near the tail end, so I had to 
manually upload the remaining files this morning - but still, I saved about 35 minutes of 
upload tedium.)  Overall, my site is no harder to administrate now than it was two years 
ago - the only rough spot is when I decide to do a transformation that affects the actual 
data files (a retrofit), and that's just tedious...not difficult, and not expensive.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 13:26:53 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:46 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <199911270505.VAA08984@harrier.prod.itd.earthlink.net>
Message-ID: <000501bf38db$67786540$099918d1@docuverse1>

>Also, your XML won't quite be a subset unless you disallow 
>']]>' from content.  Don't know why this was ever disallowed 
>in XML; it should only have been disallowed in CDATA sections.

The spec seems to qualify the restriction against ']]>' to the
CDATA section except the production rule seems to say it is
a general restriction on all character data content.  I too
do not see why it is there.

Regarding encoding.  Would it be acceptable if SML did not
mention encoding at all?  This would leave it to the context
to dictate encoding.  It also allow a future spec to define
a special tag that serves the same purpose as XML declaration.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 13:51:31 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:46 2004
Subject: [SML] Internationalization. (Preliminary EBNF for SML)
In-Reply-To: <011801bf38ae$43018020$5df5c13f@PaulTchistopolskii>
Message-ID: <000601bf38de$d8c8d9c0$099918d1@docuverse1>

>Conclusion.  I think the best approach could 
>be: 
>
>1. Only English *elements* ( but 'any'  content)
>in SML version 1.  
>
>2.  'Any'  encoding  anywhere in SML version 2.

Right.  I would be utterly stupid to even suggest
that content be restricted to English.  Dropping
the encoding issue in the SML spec might not
be a bad idea.  As I wrote in my reply to Joe Lapp,
we can introduce an element for inline encoding
hint.

BTW, I just loved your comment regarding "perfect"
translators.  Their perfection causes much head-scratching
all around the world.  They must be petrified of being wrong.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 14:05:01 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:46 2004
Subject: #2 Re: [SML] Whether to support Attribute or not?
In-Reply-To: <007501bf38a4$f7a745f0$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000701bf38e0$be316080$099918d1@docuverse1>

>Since you are not asking for use-cases, the only logic
>driving SML is reductionism. The result can only
>be a language with 1 encoding and 1 tag and the 
>minimum repertoire for names.
>
>SML = (data | "<" ASCII* ">" SML "<" ASCII* ">"  )*
>
>Given this, discussion seems utterly futile.

Rick,

You logic escapes me and I am afraid your next
deduction will be that I do not exist.  Please
allow me to have a say in what I say.  Also,
allow me to point out that taking part in a
futile discussion is, well, futile.

Since both of us seem to be rather emotionally
charged, I declare that my previous paragraph
was in jest and not in spite.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 14:25:18 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:46 2004
Subject: Why no ']]>' in CharData?
Message-ID: <000901bf38e3$93f67f00$099918d1@docuverse1>

Here is something that puzzles me.

The XML spec states that:

"In the content of elements, character data is any string
of characters which does not contain the start-delimiter
of any markup. In a CDATA section, character data is any
string of characters not including the CDATA-section-close
delimiter, ']]>'."

Second sentence seems to be saying that CDATA-section-close
is not allowed only in a CDATA section yet the production
rule for CharData is:

[14]  CharData ::=  [^<&]* - ([^<&]* ']]>' [^<&]*) 

What is the reason for special treatment of ']]>' in
character data?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 14:52:50 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:46 2004
Subject: Announce: Weblog Monitor and XML
Message-ID: <02b501bf38e7$928ce010$1918ccce@murphy>

Good morning XML developers!

I have another application of XML to announce this morning.

About a week ago we put up an app called Weblog Monitor. 

There's an HTML interface for this app, and an XML interface, which is explained here. 

But first..

***What is a weblog?

A weblog is an oft-maintained site that points to articles elsewhere on the web, often with comments, and to on-site articles. A weblog is kind of a continual tour, with a human guide who you get to know. There are many guides to choose from, each develops an audience, and there's also comraderie and politics between the people who run weblogs, they point to each other, in all kinds of structures, graphs, loops, etc. 

They also point up, in a sense, to the sites they read. On Scripting News I tend to point to stories on Infoworld, Wired, MacWEEK, MSNBC, NY Times, Red Herring, and at technical sites, centered around scripting, or what I perceive scripting to be. There are literally hundreds of these sites, and some people think there will be many thousands by the end of next year. (I am one of those people.)

***Software for weblogs

This opens the door for tools for creating and running weblogs, or ranking and organizing the sites, or providing filtered front-ends, to make the exploding variety comprehensible to a human mind. Such tools have been developed and more are coming. (Hint hint.)

And of course since all these apps are web apps, the immediate question is "How do you share the data?"

And the answer would have to be XML. 

(But we all knew that. ;->)

***How Weblog Monitor works

It's a HTTP/HTML application running on:

http://subhonker2.userland.com/weblogMonitor/

The home page displays an hourly calendar. Each weblog is listed once in the calendar, in the time slot when it last changed. The calendar is displayed in reverse-chronlogical order. By visiting the home page, you can quickly scan down the list and find weblogs that changed. The goal was to create a single page where you could watch activity on the weblogs, and it works pretty well. I've met a lot of new webloggers using this tool. It's public and free, you can use it too.

***It's an XML app

That's the HTML interface, but it's also an XML app. This means that if you can think of a better use of the data, it's open, public and you can do it. I hereby give you permission to read the XML files, no more than once an hour please, and do anything you want with the information. I ask that if you put up a public app that you send me a pointer so I can tell Scripting News readers about it.

The two files that are available thru XML are:

1. http://static.userland.com/weblogMonitor/changes.xml

2. http://static.userland.com/weblogMonitor/logs.xml

#1 is an XMLization of the calendar on the home page, and #2 is a mirror of the (growing) database of weblogs. 

Both are updated once an hour, usually before 2 minutes past the hour. (That could change as the number of registrations goes up.)

***RFC

There's also a discussion group on the site:

http://subhonker2.userland.com/weblogMonitor/discuss/edit/newTopic

Comments, questions, suggestions are welcome here or on the site.

Hope you like it!

Dave

PS: Leigh Dodds does a weblog pointing to important messages on the XML-DEV list called eclectic, it's in the rotation at Weblog Monitor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991127/a397628a/attachment.htm
From mike.champion at softwareag-usa.com  Sat Nov 27 15:06:26 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:46 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
References: <199911270737772.SM01048@Unknown.>
Message-ID: <009101bf38e8$f7cf7680$b9bdb3c7@sagus.com>


----- Original Message -----
From: <rev-bob@gotc.com>
To: <xml-dev@ic.ac.uk>
Sent: Saturday, November 27, 1999 7:40 AM
Subject: re: Re: Why I Hate Palmtops (was: Re: SGML, XML and SML)


>What sort of people *do* want to access the Web through a tiny cellphone
> screen

People sitting in traffic jams, taxis, airports, hotel lobbies, waiting
rooms, etc. where they don't have convenient or affordable access to an
internet device with a conventional form factor.  I remember sitting in a
traffic jam in Manila last month, and a colleague in the car had an "a HA!"
experience where he grokked the concept of cellphone web browsing for the
first time.... some question came up that we could answer in 30 seconds with
web access.

> I have suggested some possible avenues that might get around this
> visual real estate  problem - for instance, bypassing the screen >
> idea entirely and using text-to-speech
> rendering, or going outside the current palmtop form factor to
> something which would
> allow for a larger screen via the clamshell metaphor.
>  However, the existence of these
> possibilities does not justify XML parsers in current-metaphor
> devices.  Should a
> cellphone have an XML parser?

Why not?  Just as we're now seeing server-side translation from XML to WML,
I could imagine a client-side translation to speech.  I'd DEFINITELY want to
send the text to the cellphone in XML (or SML, or some structured markup
language) so that the text-to-speech rendered only the most salient parts of
the content.

I think the real argument for XML parsers in a cellphone is in message
processing, not text display.  I can imagine running a VERY SMALL program on
my cellphone to sniff my message headers for anything marked critical or
anything from my wife or my boss and only downloading these.  I can imagine
doing this much more easily with an XML-ish parser than without one.

In other words, I can imagine reading my high-priority e-mail and accessing
travel site from my cellphone even if I can't imagine accessing YOUR Web
site that way, Rev. 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rose at tele.dtu.dk  Sat Nov 27 16:15:39 1999
From: rose at tele.dtu.dk (Michael Rose)
Date: Mon Jun  7 17:17:46 2004
Subject: Why I Hate Palmtops
In-Reply-To: <199911270737772.SM01048@Unknown.>
References: <199911270737772.SM01048@Unknown.>
Message-ID: <v04210100b465b16840b2@[212.242.17.37]>

rev-bob asks:
>
>Hence, I'm asking what I thought would be a really simple question - 
>"What am I not
>getting?"  What sort of people *do* want to access the Web through a 
>tiny cellphone
>screen?


It might be helpful to turn your question around to "What net-based 
information do I want to access through my small mobile device?"

weather and traffic forecasts, the address of that meeting in my 
Web-based calendar which I forgot to write down.....I don't want to 
surf or pull up Web pages, I want simple pieces of information that 
have been updated since I was last on a computer or which I forgot to 
stuff into my brain before I shut it down (the computer, not my 
brain).

HTH

Michael


 

************************************************
Michael Rose
Center for Tele-Information,    Technical University of Denmark
mailto:rose@tele.dtu.dk         http://www.cti.dtu.dk/personal/rose
Multimedia in the Home - http://mmhome.cit.dk
'and what is the use of a computer' thought Alice 'without pictures
or conversation'               with apologies to Lewis Carroll
*************************************************

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Sat Nov 27 16:53:01 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:47 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
References: <007501bf38a4$f7a745f0$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <006101bf38f7$df579600$98d18dce@sagus.com>


----- Original Message -----
From: Rick Jelliffe <ricko@allette.com.au>
To: <xml-dev@ic.ac.uk>
Sent: Saturday, November 27, 1999 1:59 AM
Subject: #2 Re: [SML] Whether to support Attribute or not?


> If people are serious, they should first establish some use-cases
> of where XML fails.  This will also bring out the ramifications
> of simplicification.

My own use case for the failures of XML is XML-DEV!  We spend a majority  of
our bandwidth discussing the most obscure and least useful bits of the spec
(e.g., Does Production 14 forbid the string "]]>" in all CDATA elements, or
just CDATA marked sections?).

My experience with the DOM WG *and* my recent day jobs  is similar -- the
least useful parts of XML cause the most work for people supporting it.
Both CDATA sections and external parsed entities caused *massive* amounts of
work and contention for us in devising the DOM API.

The recent xml.com article helped me clarify my thinking here:  XML simply
has "entia multiplicanda praeter necessitatem", and (as the owner of a
long-haired dog and a long-haired cat) I've learned that a good application
of Occam's Razor to remove the hairballs may be unpleasant, but it will make
everyone happier in the long run.


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



From beavis at proteometrics.com  Sat Nov 27 17:16:59 1999
From: beavis at proteometrics.com (Ronald Beavis)
Date: Mon Jun  7 17:17:47 2004
Subject: unsubscribe
Message-ID: <001001bf38c7$d07d8e80$b0e6a1cf@videon.wave.ca>

unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991127/2e6a9a5f/attachment.htm
From digitome at iol.ie  Sat Nov 27 17:24:46 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:17:47 2004
Subject: RSS and WAP
Message-ID: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie>

Anybody know of any work afoot to extend RSS for use
with display challenged devices such as first generation
WAP phones?

regards,



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



From KenNorth at email.msn.com  Sat Nov 27 17:37:10 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:47 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
References: <199911270737772.SM01048@Unknown.>
Message-ID: <006801bf38fe$4c55c000$0b00a8c0@grissom>

> I just don't grok the reason for a screen on a cellphone; granted, it's a
> neat gadget, but so far it strikes me as an almost-totally *useless*
gadget.

There was an interesting case study at the Giga Information Group EIA 99
conference about an enterprise application using Samsung Smart Phones. A
project manager from TECO described a scheduling application they
implemented using Samsung Smart Phones. TECO is one of Florida's electrical
utilities and the goal of the application was to provide a better scheduling
window for customer service calls (e.g., cut off the power).

The Smart Phone is programmable and has a browser. The technicians use the
phone to download their work schedules, and to report when a task is
complete. This allows TECO to give customers a 2-hour window when a service
technician will arrive.

The new application eliminated a trip and allows the technicians to be based
at home. They no longer drive in the morning to a TECO office to pick up
their daily work schedule.




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



From xml-dev at teleo.net  Sat Nov 27 17:38:46 1999
From: xml-dev at teleo.net (Patrick Phalen)
Date: Mon Jun  7 17:17:47 2004
Subject: XML Application Servers
In-Reply-To: <m3d7swyyl3.fsf@picasso.o3.co.uk>
References: <C10B7E3A3AC3D211804E0000B45EDA8435D3BF@mail.imediation.com> <m3d7swyyl3.fsf@picasso.o3.co.uk>
Message-ID: <99112709401801.01833@quadra.teleo.net>

>From your (Mike's) description, it sounds like Zope is within spitting
distance of providing everything you need, with the additional
advantage of being scriptable in Python.

It has the hashed object store, ORB, the document template
processor, the clear separation of control and content, and the ability
to dynamically control display of forms, etc. It also has the
infrastructure for fine-grained access control. I believe the missing
XML pieces are already being worked on, but you could easily add what
the Zope group calls a "Product" to supply them.

Take a look: http://www.zope.org


[Mike Williams, on Sat, 27 Nov 1999]
:: Mike> The servlet collects output data in a hash-table.  Then, I (plan to)
::   Mike> run a template-processor, which splices this data into existing XML
::   Mike> templates, constructing an abstract view of the page.
:: 
::   Sebastien> Sound similar to the Cocoon publishing framework, expect that
::   Sebastien> your control logic is handled by the servlet itself.  This
::   Sebastien> latter point should, IMHO, be also XML driven, a la XSP (still
::   Sebastien> from Cocoon), 
:: 
:: Hmm. Cocoon is doing very good things, and I took a good look at XSP, but
:: it didn't quite meet my needs.
:: 
::   Sebastien> logic description -SHOULD NOT- be hard-coded in servlet but
::   Sebastien> rather scripted, and eventually compiled on the fly by the
::   Sebastien> server processor.
:: 
:: Well ... the sample XSP code I've seen uses Java as a scripting language,
:: so it's not as though coding is easier.  Though I do like the idea of
:: compiling XML into Java code that produces DOM nodes (or SAX events).
:: 
:: Let me explain why I chose to "do my own thing".  
:: 
::   * XSLT is good for _transforming_ documents, to apply a style.  However,
::     it's not so good for assembling document components.  For this, a
::     template-like system makes more sense.
:: 
::   * Similarly, XSLT is good for duplicating markup, ie. which is not so
::     good when your markup includes code. If you put code in a XSP
::     logic-sheet, then apply this to a number of content documents, it seems
::     to me that you'd end up generating a number of pages containing
::     identical code.  Messy.
:: 
::   * Cocoon XSP is not yet a reality, only a work-in-progress.
:: 
:: This is my current world-view:
:: 
::   * Control *logic* should be in control of what *presentation* method to
::     use, and what *content* to include.
:: 
::   * Templates are a useful way to define data-independent presentation. It
::     should be possible to include other templates, allowing a page to be
::     built out of re-usable fragments.
:: 
::   * Templates should be able to display content from different
::     sources. They should be *provided with* content to present, rather than
::     knowing how to go out and get it.
:: 
::   * Likewise, it should be possible to display the same content in
::     different ways.  So, the content shouldn't (directly) imply the
::     presentation mechanism.
:: 
:: I need this flexibility because of the requirements of my current project,
:: which is a database-backed web application.
:: 
::   * Dynamically created forms. On some screens, data-entry fields are
::     generated dynamically from the database, depending on what's
::     appropriate for the object being edited.
:: 
::   * Context-sensitive help. We need to be able to provide help for each
::     screen of our application, describing the forms, fields, links etc on
::     that screen.  This includes the dynamic screens mentioned above.  To do
::     this, we plan to include help-text in our screen templates, and use
::     alternate style-sheets to display either the help or an editable
::     screen.
:: 
::   * User-visible text (labels, help, etc.) cannot be hard-coded in the
::     screen templates, but must be but sourced from external
::     configuration-files. 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 17:45:30 1999
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun  7 17:17:47 2004
Subject: RSS and WAP - another RSS question
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie>
Message-ID: <384018F6.182C7EFC@finetuning.com>

Sean Mc Grath wrote:
> 
> Anybody know of any work afoot to extend RSS for use
> with display challenged devices such as first generation
> WAP phones?
> 
> regards,
> 


In this same vein, while you're at it (nice person who is going to
answer the question), could you also explain why anyone would NEED this
service (WAP/RSS), and, if possible, the practical usefulness of RSS in
general (if any).

I'm having trouble understanding why or if RSS even matters (despite its
apparent level of widespread adoption) and am trying to determine its
level of inclusion in my books/classes.

thanks,

lisa

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



From martind at netfolder.com  Sat Nov 27 18:21:19 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:47 2004
Subject: About SML and internationalization
Message-ID: <NBBBJPGDLPIHJGEHAKBAKEMIEHAA.martind@netfolder.com>

Hi,

Rick Jelliffe said:
I agree that it is good to have standard
terms for common things, and that English is the best choice
at the moment, but unfortunately not every word exists in
English and most people in the world do not speak it or read
it.

Why reduce markup to mere nmemonics rather than be able
to use names?

didier says:
I totally agree with Rick.

Don, how would you, in English, markup a text talking about snow? In the
Inuit language (you know these people living up north of Canada) there is
approx. 30 different words to qualify snow. To be able to qualify snow up
there and therefore being able to markup text about snow requires a deep
knowledge of it and thus, have words to express this knowledge. How many
words an average English engineer has for snow?(I mean the average
non-intuit english speaking engineer)

No, Don, to restrict SML solely to English is a bit a "monopolistic" view of
the world isn't it? As far as I know, we are trying to resolve some problem
that monopolies brought to us, not trying to create new ones (I do not mean
us in this group, I mean us as a society and some group who not necessarily
behaved for our best interest, maybe not their fault. It is like in the
godfather movie where the principal character said: Its just business :-)

I suggest that we refer a bit about the philosophy language. Is the language
a mirror of the knowledge or is the knowledge independent of the language?
we still don't know. However, what we do know, and people fortunate enough
to speak more than language know (if they are fortunate enough to have this
wisdom), is that each language leads you to a different view of the world.
If we use words to create markup tags then a markup has some meaning for a
particular culture. You may be able to express some concepts in some
languages with a simple words (therefore an element name) and in some other
languages as a sentence (hard to transform that into an element's name :-)

To take a concrete example, for those fortunate enough to have a Unicode
editor or viewer just take a look at the text I included with the message.
It is a text I got from Jon Bosak. The text is marked up in Japanese but the
content is not. Just take a look to this document. Make some silence in your
head and then as you look at it, just represent in your mind that on the 6
billion people on earth, a tiny fraction is English speaking. Just look at
the document, make silence in your head and let it bring to you some
awareness about the impacts of having an English only markup system. Make
some silence in your head, and let the document give you the awareness that
even if American maps show the American continent as its center, that the
earth is in fact a sphere and that there is no such center. Make some
silence, and remember how we are now calling the epoch where it was
forbidden to even think that the sun may be at the center of our immediate
universe (i.e the solar system). Finally let this text tell you that a big
majority of the world is not English speaking. By the way, how do feel to
look at a non English markup? And if you do not have an editor that can show
you this text and its markup then ask to yourself why? The text may have no
meaning for you but it certainly has for someone talking this language. Just
let the text tell you that there is something else outside USA.

Sorry, I had to say that even if I think that the SML reflection and all the
whys it brings to the surface is like fresh air and brought a talk that is
no longer behind closed doors and that this talk finally founds its way to
the public place. This is progress and the inalienable right to challenge,
discuss, question the status quo, which is, in the essence of science.
Finally, we are maybe altogether finding the whys and how behind some
decisions - good, bad or just compromises. And also, maybe a good occasion
to let us understand what XML is, after all. And why not, improve it but not
to the detriment of 85% of the planet.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com
-------------- next part --------------
??<?xml version="1.0"?>

<!DOCTYPE ?fM|?0?0?0?0 [

  <!ELEMENT ?fM|?0?0?0?0 (?fM|)+ >

  <!ELEMENT ?fM| (?f
T,W??,?QHr>y,(?[?O | (W?^pe)) >

  <!ATTLIST ?fM|	xml:lang CDATA #REQUIRED >

  <!ELEMENT ?f
T	(#PCDATA) >

  <!ELEMENT W??	(#PCDATA) >

  <!ELEMENT ?QHr>y	(#PCDATA) >

  <!ELEMENT ?[?O	(#PCDATA) >

]>



<?fM|?0?0?0?0>

  <?fM| xml:lang="JP">

    <?f
T>XMLeQ??</?f
T>

    <W??>Qg0u
0????
0R??N</W??>

    <?QHr>y>?e,gL}n?e^?>y</?QHr>y>

    <?[?O>2800</?[?O>

  </?fM|>

  <?fM| xml:lang="EN">

    <?f
T>Developing SGML DTDs</?f
T>

    <W??>E. Maler and J. el Andaloussi</W??>

    <?QHr>y>Prentice Hall</?QHr>y>

    <?[?O>50</?[?O>

  </?fM|>

</?fM|?0?0?0?0>


From ebohlman at netcom.com  Sat Nov 27 19:09:51 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:47 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <009101bf38e8$f7cf7680$b9bdb3c7@sagus.com>
Message-ID: <Pine.GSU.4.10.9911271049070.17946-100000@netcom6.netcom.com>

On Sat, 27 Nov 1999, Michael Champion wrote:
> People sitting in traffic jams, taxis, airports, hotel lobbies, waiting
> rooms, etc. where they don't have convenient or affordable access to an
> internet device with a conventional form factor.  I remember sitting in a
> traffic jam in Manila last month, and a colleague in the car had an "a HA!"
> experience where he grokked the concept of cellphone web browsing for the
> first time.... some question came up that we could answer in 30 seconds with
> web access.

I think you've put your finger on it.  The primary usage mode for data
display and transmission on "small" devices is going to be "ask a question
and get an answer," not "load this bunch of narrative prose so I can read
it."  It's going to be "ask the railroad when the last train leaves this
station," not "let me read the railroad's timetable."  It's not going to
be about "viewing Web sites" in the way we currently understand it.  The
"surfing" metaphor isn't applicable here.  It's a query/response scenario,
not a document/view scenario.  It's definitely *not* a "have a
producer-defined experience" scenario.

In short, it's going to be a usage of the Web that has few if any
parallels with existing print and broadcast media.  Existing media are
based on the notion of delivering identical copies of some content to a
mass audience, and most "Web pages" are just variations on this idea.
rev-bob is, IMHO, correct in that trying to use a cellphone or palmtop as
a viewer for such media is at best a novelty.  What we're really talking
about is the on-the-fly creation and/or extraction of customized snippets
of content.  The Real Life analogies for this don't lie in the world of
media and publishing; they lie in the area of "call someone and ask them a
question."



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 19:22:17 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:47 2004
Subject: RSS and WAP - another RSS question
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie> <384018F6.182C7EFC@finetuning.com>
Message-ID: <034001bf390d$3bf56800$1918ccce@murphy>

Sure, I'll take a stab at it.

See the commercials on TV for wireless phones that double as web browsers?

Not much room in that space. Room for one headline and perhaps a channel
name.

Flip thru a dozen or so stories, queued up, see one that tweaks you, find a
real web browser and view the same page in all its HTML glory, same stories,
banner ads, etc.

I'm not that wired myself, I have a circa 1996 cellphone, no beeper, no fax.

But you see the cellphone people everywhere.

Anyway, I don't know what Sean has in mind, but this seems like a no-brainer
app for RSS, or something doing pretty much the same thing. (Reinvented
wheels.)

Dave


----- Original Message -----
From: Lisa Rein <lisarein@finetuning.com>
To: <xml-dev@ic.ac.uk>
Cc: Sean Mc Grath <digitome@iol.ie>
Sent: Saturday, November 27, 1999 9:46 AM
Subject: Re: RSS and WAP - another RSS question


> Sean Mc Grath wrote:
> >
> > Anybody know of any work afoot to extend RSS for use
> > with display challenged devices such as first generation
> > WAP phones?
> >
> > regards,
> >
>
>
> In this same vein, while you're at it (nice person who is going to
> answer the question), could you also explain why anyone would NEED this
> service (WAP/RSS), and, if possible, the practical usefulness of RSS in
> general (if any).
>
> I'm having trouble understanding why or if RSS even matters (despite its
> apparent level of widespread adoption) and am trying to determine its
> level of inclusion in my books/classes.
>
> thanks,
>
> lisa
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 19:32:34 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:47 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <004501bf38a0$f30c84f0$42f96d8c@NT.JELLIFFE.COM.AU> from "Rick Jelliffe" at Nov 27, 99 02:30:26 pm
Message-ID: <199911272032.PAA02086@locke.ccil.org>

Rick Jelliffe scripsit:
> 
>  
> From: Don Park <donpark@docuverse.com> 
> 
> >Internationalization is also less of a problem than you
> >think. 
> 
> This is utterly bogus.  Every different language and domain
> area has different problems.   

Indeed.  In fact, I believe the true law of i18n is:
"the problem is *always* harder than you think, even when you
have taken this law into account"!

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 19:35:12 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:47 2004
Subject: RSS and WAP - another RSS question
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie> <384018F6.182C7EFC@finetuning.com> <034001bf390d$3bf56800$1918ccce@murphy>
Message-ID: <035a01bf390f$06fa68b0$1918ccce@murphy>

A couple more thoughts:

1. Of course you'd use the full HTML page and a real computer to choose the
channels you want to appear in your cellphone display. Kind of like
My.Netscape or My.UserLand, but a specific set of options for your other
smaller display.

2. Of course since it's a cellphone you could have it read the story to you.
Duh.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From xml-dev at teleo.net  Sat Nov 27 19:39:27 1999
From: xml-dev at teleo.net (Patrick Phalen)
Date: Mon Jun  7 17:17:47 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <009101bf38e8$f7cf7680$b9bdb3c7@sagus.com>
References: <199911270737772.SM01048@Unknown.> <009101bf38e8$f7cf7680$b9bdb3c7@sagus.com>
Message-ID: <99112711405902.01833@quadra.teleo.net>

[Michael Champion, on Sat, 27 Nov 1999]

   [Rev-Bob]
:: >What sort of people *do* want to access the Web through a tiny cellphone
:: > screen
:: 
:: People sitting in traffic jams, taxis, airports, hotel lobbies, waiting
:: rooms, etc. where they don't have convenient or affordable access to an
:: internet device with a conventional form factor.  I remember sitting in a
:: traffic jam in Manila last month, and a colleague in the car had an "a HA!"
:: experience where he grokked the concept of cellphone web browsing for the
:: first time.... some question came up that we could answer in 30 seconds with
:: web access.

I have been developing automated news services, including
"real-time" traffic reports delivered on the Web and via email in major
U.S. markets for five years. They have always been extremely
popular. Over time, the core text traffic reports have been enhanced
with richer information (fine-grained geocoding, color maps overlayed
with speed sensor data and incident markers, webcams, etc.) which isn't
currently appropriate for tiny displays. Yet the text information
continues to sit at the core, is timely and invaluable to commuters,
and can be repurposed as email or WML.

We're already delivering news, weather, and traffic services via email
to pagers as we wait for XML tools and standards (and WAP) to cohere.

I know firsthand that commuters in traffic nightmares like New York,
Boston, and Silicon Valley are more than willing to put up with the
shortcomings of palmtop displays to get timely traffic data, along with
their stock market and weather information.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 19:49:10 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:48 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <199911270737772.SM01048@Unknown.> from "rev-bob@gotc.com" at Nov 27, 99 07:40:58 am
Message-ID: <199911272048.PAA02602@locke.ccil.org>

rev-bob@gotc.com scripsit:

> Oh, to swipe a bone from the SML threads, here's another thing to
> toss in.  I have a hard time visualizing radical internationalization
> on a tiny screen.  Anglo-centric characters, I get.  Asian scripts
> and Cyrillic...well, those seem a bit out of range.

I don't know what Cyrillic is doing here: whatever can represent Latin
can represent Cyrillic (except a nixie tube, I suppose!).

> Again, am I
> missing something?  Call me strange, but I just don't see the pixel
> density on current palm/cell screens being big enough to display
> a reasonable amount of Kanji data.

Traditionally, Han characters are displayed at double the width
of alphabetic ones, in limited-resolution environments.  Considering
that in Chinese the ratio between romanized and Han forms of text
is 3.5:1 or so, and in Japanese it may be as much as 8:1 in particular
cases, this seems a very reasonable tradeoff.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 19:51:13 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:48 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to
 support Attribute or not?)
In-Reply-To: <006101bf38f7$df579600$98d18dce@sagus.com>
Message-ID: <Pine.GSU.4.10.9911271112430.17946-100000@netcom6.netcom.com>

On Sat, 27 Nov 1999, Michael Champion wrote:
> My own use case for the failures of XML is XML-DEV!  We spend a majority  of
> our bandwidth discussing the most obscure and least useful bits of the spec
> (e.g., Does Production 14 forbid the string "]]>" in all CDATA elements, or
> just CDATA marked sections?).

Warning!  Selection bias alert!

The most difficult and problematic aspects of a system are always going to
be the ones that generate the most discussion and questions; people don't
spend much time on mailing lists talking about the easy parts that
everyone already understands.  The boundary cases are always going to get
the most "coverage."  Just like in the Real World where rare events get
more news coverage than commonplace ones.  The murderer who gets off on a
technicality gets far more coverage than the murderer who's sentenced in a
quick trial, so just looking at the news gives you an impression of a
justice system that's seriously broken.

> My experience with the DOM WG *and* my recent day jobs  is similar -- the
> least useful parts of XML cause the most work for people supporting it.
> Both CDATA sections and external parsed entities caused *massive* amounts of
> work and contention for us in devising the DOM API.

I'm inclined to consider that a unique case.  CDATA sections and external
parsed entities (and for that matter, comments) have to be treated
specially by the DOM in order to accommodate a narrow class of
applications, namely editors and editor-like programs, that need to be
able to reconstitute the purely lexical structure of a document after
modifications.  The vast majority of applications using XML have no need
to know whether a particular string of characters appeared in an external
entity or a CDATA section.  An editor does.  Someone writing a non-editor
application doesn't need to master the methods for querying lexical
structure.  Their presence may make the DOM complex to implement, but not
to use.

But it's almost always the case that the design of development tools for a
system is much harder than the design of application for that system.
The complexity added to the development of the DOM specification, or even
a DOM implementation for a particular platform, is a one-time thing; it
doesn't get duplicated every time someone *uses* the DOM API.

As an example, a programming language that has an LL(1) grammar is going
to be much easier to write a compiler for than a language whose grammar
isn't even context-free, but that does *not* imply that it will be easier
for a programmer to write code in the first language.  If you're going to
say that the second language is "difficult," you need to specify *whom*
it's difficult for.  If the answer turns out to be, as it usually is,
something other than "everyone," you need to make some value judgments,
and the one usually made is that difficulty in doing rarely-done things
(like writing a compiler for the language) is worth it if the result is
less difficulty in doing frequently-done things (like writing programs in
the language).  It's very often the case that external simplicity is the
result of internal complexity.  Mathematical elegance rarely translates
into ease of use.  A minimalist set of primitives *may* be easier to
*learn* (especially if you're talking about learning as memorization
rather than learning as comprehension) than something richer, but it may
also be harder to *use* (the set of Turing-machine primitives can be
completely learned in an hour, but they're not easy to write programs
with).



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 19:52:36 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:48 2004
Subject: XML:  Still Just HypedWebStuff
In-Reply-To: <199911270822811.SM01048@Unknown.> from "rev-bob@gotc.com" at Nov 27, 99 08:26:02 am
Message-ID: <199911272052.PAA02661@locke.ccil.org>

rev-bob@gotc.com scripsit:

> > It's easy enough to demo this sort of thing on my notebook with ten sample
> > documents, a browser and a couple of Perl scripts, but it turns out to be very hard
> > and expensive to implement in a high-volume, high-performance environment.
> 
> And I say, not necessarily.  Take the lexical transformation above - wire the list of terms 
> up to a grep bot, and it doesn't much matter whether you're handling ten documents or 
> ten thousand.

High-volume in this context probably means hundreds of millions of
documents.  High performance probably means hundreds of thousands
of hits per second.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 20:06:27 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:48 2004
Subject: About SML and internationalization
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAKEMIEHAA.martind@netfolder.com> from "Didier PH Martin" at Nov 27, 99 01:18:11 pm
Message-ID: <199911272106.QAA03249@locke.ccil.org>

Didier PH Martin scripsit:

> Don, how would you, in English, markup a text talking about snow? In the
> Inuit language (you know these people living up north of Canada) there is
> approx. 30 different words to qualify snow.

*sigh*.  The correct number of words is four.
See http://www.urbanlegends.com/language/eskimo_words_for_snow_more.html .

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From xml-dev at teleo.net  Sat Nov 27 20:06:35 1999
From: xml-dev at teleo.net (Patrick Phalen)
Date: Mon Jun  7 17:17:48 2004
Subject: RSS and WAP - another RSS question
In-Reply-To: <384018F6.182C7EFC@finetuning.com>
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie> <384018F6.182C7EFC@finetuning.com>
Message-ID: <99112712081303.01833@quadra.teleo.net>

[Lisa Rein, on Sat, 27 Nov 1999]

:: In this same vein, while you're at it (nice person who is going to
:: answer the question), could you also explain why anyone would NEED this
:: service (WAP/RSS), and, if possible, the practical usefulness of RSS in
:: general (if any).

In general (and outside the discussion of WAP) RSS provides a model for
news syndication. That, in turn, enables its obverse, namely news
aggregation. See Dave Winer's essays at http://www.scripting.com for
evangelism on this subject.

Portal sites have been hugely hyped, but their offerings boil down to
whatever content their owners control through deals for equity
participation or licensing. Thus, no portal gives me (or you) exactly
the choice of information you want in one location.

Imagine having an XML browser allowing you the freedom of choice to
custom assemble all this timely push-channel-content in the form and
variety you choose, combined with the additional abilities of
interacting with your appointment calendar, expense reports, bank and
credit card balance, email, etc. in one Web-based interface.

RSS (and ICE, etc.) granulates news on the Web. XMLNews and its
successors will do an even better job of this, seemingly sounding the
death knell for the current news concentrator portal strategy.

And that's big news. ;)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 20:28:41 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:48 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <383F802D.E9F85303@cs.ucsd.edu>
Message-ID: <Pine.GSU.4.10.9911271219500.24101-100000@netcom6.netcom.com>

On Fri, 26 Nov 1999, Pavel Velikhov wrote:
> I am not a frequent participant here, but I am opposed 
> to the use of attributes in the XML as it is happening 
> right now. What I don't like is the way query languages 
> for XML suffer because of the attributes.
> 
> Attributes require a special syntax in the XML query 
> languages, just like in XML itself. Instead
> of writing OQL-ish path expressions like:
> 	homes.home.id
> 
> you will have to write:
> 	<homes> <home id=_ /> </homes> in XML-QL or similar
> languages. XQL also does not treat attributes and element
> equally.

But that's merely a design decision on the part of the designers of the
two query languages, *not* an inherent limitation.  It would be perfectly
possible to design and implement a query language that treated an
element's attributes the same as text-only child elements of that
attribute.

Do remember that XML is not inherently "object-oriented," whatever that
phrase means nowadays.  There are plenty of XML uses that involve
structured text, not serializations of objects.


> 
> If you don't know whether the object you are picking is an
> attribute or an element, you will have to write a disjunction.
> There could also be a case when an element has an attribute
> and a subelement with the same name, you might have to
> guard against such case. I.e. things get messy fast.
> 
> So I think if attributes are out, a lot of XML tools, including 
> query processors will get simpler. Also there will be less 
> opportunity for the users to screw up when using these tools.
> 
> Pavel Velikhov
> pvelikho@cs.ucsd.edu
> http://www.db.ucsd.edu
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 20:31:30 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:48 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000901bf38e3$93f67f00$099918d1@docuverse1>
Message-ID: <Pine.GSU.4.10.9911271229501.24101-100000@netcom6.netcom.com>

On Sat, 27 Nov 1999, Don Park wrote:
> What is the reason for special treatment of ']]>' in
> character data?

See the third paragraph of Section 2.4 of the Recommendation.  It's there
for compatibility, i.e. so an SGML processor can parse an XML document.



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



From martind at netfolder.com  Sat Nov 27 20:38:23 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:48 2004
Subject: About XML document linkage and Schemas.
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90A6@sohos002.ied-support.net>
Message-ID: <NBBBJPGDLPIHJGEHAKBAGEMLEHAA.martind@netfolder.com>

Hi Mark,

Sorry for the delay for an answer but your comment required some thoughts.

Form the point of view of validity (as per the XML 1.0 recommendations) you
are right. it is not valid to embed a RDF element if this latter and its
descendant are not included in the document's DTD. But, on the contrary, it
is valid (as per the XML 1.0 recommendation) to embed the <MyInvoice>
element into a <rdf:description> element. So, I won't comment about the
philosophy to have a meta data format to include the document or the
contrary neither if RDF is even meta data or simply a different data model,
neither will I say that one is better than the other. I'll just play the
rules and see if these are incongruous, strange or simply too restrictive
today in the light of what we try to do or in the light of what we learned
to do.

Funny things that we can observe today with the current XML framework:

a) We can include a link to a style sheet in a document and have this
document valid as per the XML 1.0 recommendation. This mainly because the
link takes the form of a processing instruction. A Funny thing also to note
is that the style sheet reference is at the same time a link and, from an
other point of view, a processing instruction. And also, that from the
document structural point of view a non existing thing or a new incarnation
of the invisible man.

If, because of transportation constraints, we have to include the entire
style sheet content in the document, then the <xsl:stylesheet> element and
all its descendents (i.e. children) would have to be included in the
document's DTD to be parsed with validity in mind. Thus, in order to have
the original document structural integrity respected (always from the XML
1.0 point of view), we cannot create a compound document (document composed
of fragments and all the fragments resident in the same text "package") and
thus, we are restricted to link to the outside style sheet (in a separate
text "package"), not to include it per se. In certain circumstances, to
transport a single "package" is a necessity. But under the XML 1.0
constraints we cannot at the same time include the style sheet element and
all its descendants and still consider it as valid if the style sheet and
all its descendant are not part of the document type. To create a compound
document, we therefore need to create an other format than XML in order to
carry the document and the style sheet in the same text "package". Let's
call this kind of constraint: "use case 1" (and remember the fact, that
under certain circumstances it would be easier and beneficial to have all
this information -i.e the document and its style sheet- in the same text
"package" just to minimize the ping pong effect or simply to transport the
whole in a messaging system imposing such constraints Ex: SMTP, Message
based middleware).

b) in the same vein, if we where to include a meta data reference about a
particular context concerning this document, then we can use the same
mechanism as for (a) and still respect the original document structural
integrity (I mean here without affecting it or modifying it). Thus, by
including a processing instruction used as a link to a meta data document
(i.e. an RDF document) and that this processing instruction is also
precisely used as...a processing instruction by an RDF engine then, we get
what we want. Except if we incorporate to the situation or the goal to reach
that we have the constraint of a single text "package" to transport both the
document and its meta data. To be valid as per the XML 1.0 recommendation,
the document cannot include the meta data <RDF> element without a
modification of its structure, it can only have a link to it through a
processing instruction which is like the invisible man (remember the movie?
:-) for an XML 1.0 validating parser.

c) The only thing that do not affect an XML 1.0 valid document is its DTD
itself which can be included in the same text "package" without affecting
the document integrity. Thus, the DTD and the document itself are in the
same unit.


So, what is the vision of the world from an XML 1.0 recommendation point of
view? or if XML 1.0 would be a philosopher, what would he say? That only the
document type definition is part of the document, if you want to include
something (a joke, a meta data context, a style sheet a virus, :-) in the
document without affecting its structural integrity, do it with a processing
instruction or a comment. both are the incarnation of the invisible man for
an XML validating parser.

Thus,

Let's call that use case #3 (no 1 being the style sheet affair, #2 being the
meta data affair, #3 being both, what an occupied man :-)
But now, how to aggregate things and still being able to validate them?
Waiting an answer from the Schema WG. Can we now add complementary things to
a document without affecting its structural integrity? A DTD do not affect
the structural integrity, a stylesheet does a meta data context does. But
both are complementary elements. Have we regressed from what we learned
about compound documents (remember the frameworks developed at the beginning
of the 90s just before we all became troubled by the compound documents
amnesia?) Or did we learned in fact?

So I can include new stuff not necessarily part of the original XML document
as long as I include them as processing instructions or comments. And if it
is hard to aggregate, add complementary information, create rich content,
and still be valid at the same time.

So, for an XML citizen, to be valid is too restrictive. this is why maybe,
most of these citizen are choosing to be only "well formed"

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sat Nov 27 20:52:21 1999
From: ejfreed at infocanvas.com (Erik James Freed)
Date: Mon Jun  7 17:17:48 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.GSU.4.10.9911271219500.24101-100000@netcom6.netcom.com>
Message-ID: <NCBBICOBAHLCGGGGCEIEIEENEOAB.ejfreed@infocanvas.com>

Then that query language would be making assumptions about the
semantic equivalence of attributes and elements with the 
same name. This seems wrong. I think the problem is harder than
you present it.

erik

> But that's merely a design decision on the part of the designers of the
> two query languages, *not* an inherent limitation.  It would be perfectly
> possible to design and implement a query language that treated an
> element's attributes the same as text-only child elements of that
> attribute.
> 

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



From martind at netfolder.com  Sat Nov 27 20:58:33 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:48 2004
Subject: About SML and internationalization
In-Reply-To: <199911272106.QAA03249@locke.ccil.org>
Message-ID: <NBBBJPGDLPIHJGEHAKBAIEMNEHAA.martind@netfolder.com>

Hi John,

Thanks for correcting my comment about the Eskimo words for snow (and I
learned something useful in the process, so many thanks for this).

This nonetheless, do not diminish the fact that for an Eskimo to be able to
markup in its own language is a minimal right and respect from the rest of
the planet toward its own culture. Also, that XML is a framework used to
create domain languages. Am right this time? And as such, a domain language
may equally well created in Japanese, Chinese, German, English, Spanish,
Portuguese, French, Russian, Norwegian, Swedish, Danish... By the way (I do
not want to make an error this time) how many different languages do we have
on our spaceship named earth?

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com

-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
John Cowan
Sent: Saturday, November 27, 1999 4:06 PM
To: xml-dev@ic.ac.uk
Subject: Re: About SML and internationalization


Didier PH Martin scripsit:

> Don, how would you, in English, markup a text talking about snow? In the
> Inuit language (you know these people living up north of Canada) there is
> approx. 30 different words to qualify snow.

*sigh*.  The correct number of words is four.
See http://www.urbanlegends.com/language/eskimo_words_for_snow_more.html .

--
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Sat Nov 27 21:30:28 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:48 2004
Subject: About sml and internationalization
Message-ID: <NBBBJPGDLPIHJGEHAKBAGEMOEHAA.martind@netfolder.com>

Hi,

First, I made again an other typo by using XML instead of SML :-)

Secondly, I thought more about SML and before going further on my comments,
I have a need for clarification.

a) is SML a framework to create domain languages?
b) is SML simply an English hierarchical information set? (that could be
qualified in this case as a particular XML domain language)

Think, before answering, it is important that we understand well what is SML
and thus keep the debate at the right level. So that Rick. me, an other
people having as a value to repect other's people language can fully
understand of what we are talking about. Or , in fact, that we all define of
what we are talking about.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Sat Nov 27 21:58:14 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:48 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether tosupport Attribute or not?)
References: <Pine.GSU.4.10.9911271112430.17946-100000@netcom6.netcom.com>
Message-ID: <003a01bf38a2$cb087610$0abdb3c7@WORKGROUP>


----- Original Message -----
From: Eric Bohlman <ebohlman@netcom.com>
To: Michael Champion <mike.champion@softwareag-usa.com>
Cc: <xml-dev@ic.ac.uk>
Sent: Saturday, November 27, 1999 2:51 PM
Subject: Re: Use cases for XML failure (was Re: #2 Re: [SML] Whether
tosupport Attribute or not?)

> The murderer who gets off on a
> technicality gets far more coverage than the murderer who's sentenced in a
> quick trial, so just looking at the news gives you an impression of a
> justice system that's seriously broken.

Good point as to why we spend our time arguing about the corner cases in
XML-DEV.  Nevertheless, the Real World can't afford the luxury of a legal
system that arbitrarily chops off the corner cases.  But we're not talking
about designing a legal system here, we're talking about designing a
dirt-simple markup language for *simple* messages and documents.  We *can*
arbitrarily decide the corner cases, because people who don't like SML's
handling of them can simply use XML or SGML.  That might cost them
something, but it won't put them in jail.

> result of internal complexity.  Mathematical elegance rarely translates
> into ease of use.  A minimalist set of primitives *may* be easier to
> *learn* (especially if you're talking about learning as memorization
> rather than learning as comprehension) than something richer, but it may
> also be harder to *use* (the set of Turing-machine primitives can be
> completely learned in an hour, but they're not easy to write programs
> with).

Another very interesting counter-example.  Clearly we need layers of
abstraction on top of whatever the underpinnings are, SML or XML or
whatever. Clearly most people are going to use the higher-level
abstractions. I'd argue that those higher-level abstractions are -- in
general -- going to be easier to build on top of a minimal, elegant
foundation.

Otherwise, the kludges perpetuate themselves.  For example, consider XML
Production #14 that we've talked about today ... it was put in to ensure
compatibility between XML and SGML parsers ... and now some people are
saying that the SML proposal "crosses the Rubicon" because it's planning to
remove this, i.e., making it possible for legal SML to be rejected by an XML
parser.

I know that I signed up for the DOM activity partly out of an innocent
belief that reasonable abstractions presented to Web programmers could help
promote XML.  Over and over again, the very things that Don is removing from
XML to make SML got in the way of defining those abstractions.

Maybe my DOM horror stories are not relevant, as Eric suggests.  I think
they are -- it's an honest effort by knowlegeable people to apply a simple
face to the complexities of XML.  Others will wrestle with that problem,
even if they don't want to!  And FAR more people are going to find that is
is strange and stupid (to belabor my favorite example today) that you can't
put the string "]]>" in an XML element without escaping it than will find it
useful to be able to parse XML with an SGML tool.





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



From jelks at jelks.nu  Sat Nov 27 22:21:13 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:48 2004
Subject: Forget SML. We need RTSML.
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAGEMLEHAA.martind@netfolder.com>
Message-ID: <NBBBICMNIPCICMKJECCBMEIBDCAA.jelks@jelks.nu>

Simple Markup Language is too hard.  We need Really Truly Simple Markup
Language.

Just like attributes (which make a document more difficult to parse, cause
religious controversies, etc.), sub-elements are troublesome.  We need to do
away with sub-elements.

Here is a typical RTSML document:

<WarAndPeace>
	English translation of War and Peace
	in its entirety goes here
	(snipped for brevity).
	...
</WarAndPeace>

With this setup, we can also do away with entities.  RTSML is English-only, so
we don't need Unicode character references.  We don't even need the predefined
entities.  The parser treats *everything* between the one and only <Tag> and
</Tag> as content.  No more worrying about < and &.

No more empty elements.  No more having to "walk" a tree.  Branches are
inherently dangerous.  When venturing out on branches while tree-climbing as
young-uns, we'd usually bust our brains out.  No more.  Shinny up and down that
single trunk without a bruise.

Here's the first draft of the EBNF for RTSML:

	document ::= StartTag Stuff EndTag
	StartTag ::= ?<? Tag ?>?
	EndTag   ::= ?</? Tag ?>?
	Tag      ::= [0-'~']+
	Stuff    ::= [0-'~']*

We expect RTSML 1.0 to be a WFeCes Recommendation on April 1, 1999 or day after
tomorrow (whichever comes first).

/Jelks


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



From gtn at ebt.com  Sat Nov 27 22:33:03 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <199911231056253.SM01008@Unknown.>
Message-ID: <000e01bf3926$c62e5950$fad45dc7@ebt.com>


> wouldn't you say?  I daresay that no amount of "slightly 
> larger display" and higher 
> resolution will compensate for this huge discrepancy.

There are some really interesting technologies coming down
the pipeline which will componsate for this. I can see, in
the not too distant future, something with roughly the form
factor of a novel, with the same resolution. 

That said, I wonder why everyone thinks jamming XML into a
phone is such a great idea, and I wonder why, when the phones
don't have the hardware needed, the answer is cutting back
XML. Fix the phones first.... the quantum leap in computing
will come from more powerful mobile devices that are 
always networked (or close to it), not things like
palm pilots.



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



From gtn at ebt.com  Sat Nov 27 22:38:24 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <003a01bf35d0$0d304480$46d88dce@sagus.com>
Message-ID: <000f01bf3927$8587cac0$fad45dc7@ebt.com>

> > probably about the only practical way to do that to any large degree.
> > (Not to mention that it automatically provides screen protection and
covers
> > the buttons!)
>
> I think that misses the point of ultralight clients!  I
> wouldn't expect to write a novel, or code, on my
> cellphone, and I don't want to lug around even
> my Sony Vaio (about 2 lb ultraslim notebook) to make phone calls.  In
> between those extremes there's a lot I *would* like to do on
> my cellphone that (being in the US) I can't do yet, like scan my email for
anything
> important, check my travel arrangements on Web sites, maybe
> read some news headlines or see how badly my lastest XML-DEV posting is
> being flamed ;~)

I don't see why you need XML for this though... I can see XML being
used on the server side, and then delivered in various forms... which
could be anything.

We used to do a nifty demo showing content (100's of MB's) stored on the
server, and delivered to PC's *and* palm pilots, with completely
different looks and feels, simply by changing a stylesheet. Heck, I
could have delivered s-expressions just as easily as HTML in those
cases, can could just as easily general binary data that would consume
far less bandwidth and processing power on the display device.

I call this "the XML as hammer syndrome"....


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



From gtn at ebt.com  Sat Nov 27 22:45:14 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <000001bf3652$75a79b80$099918d1@docuverse1>
Message-ID: <001001bf3928$7a2148e0$fad45dc7@ebt.com>

> Take a phone for example.  Your front office could send you
> some notes in XML format so that if it contains a phone number,
> the phone can display a small phone icon at the corner of the
> message and make the call for you when you press a button.  Your
> business card can be stored on your phone so that you can give
> it to another person by simply pointing it at his phone.  Another
> use might be to receive address information so that you can find it
> using cellular tri-angulation or satellite technology.

This is such a specific application that I fail to see the necessity
of XML... unless of course we imagine *all* phones
being able to deal with such messages.


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



From gtn at ebt.com  Sat Nov 27 22:59:05 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Handheld computers
In-Reply-To: <383D749E.C9A3D893@praxis.cz>
Message-ID: <001101bf392a$605e5db0$fad45dc7@ebt.com>

> Quite seriously, it is a simple fact that many of the features that
> found their way into XML are becoming increasingly redundant 
> as various auxiliary standards mature. 

The point here is that standards define minimal interoperabilityt.
The more standards you have to implement for interoperability, the
bigger the problem (i.e. you would be creating an XML that was really
an aggregate of XML+XLink+Xpointer+<whatever>), and that would be
bigger and harder than XML 1.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Sat Nov 27 23:22:50 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
In-Reply-To: <009101bf38e8$f7cf7680$b9bdb3c7@sagus.com>
Message-ID: <001201bf392d$ba1149f0$fad45dc7@ebt.com>

> I could imagine a client-side translation to speech.  I'd
> DEFINITELY want to send the text to the cellphone in XML (or SML, or some
> structured markup language) so that the text-to-speech rendered only the
most
> salient parts of the content.

The amount of computing power to accomplish this would again then
to argue against the necessity for SML. I agree that handheld devices
will be very significant in the future, I debate the necessity to
lobotomize XML in order to use them.

These devices will be significantly more powerful in the very near future,
and so should be more than capable of dealing with XML 1.0 (after all,
they'll have networking, and lot's of other stuff built in).

For highly underpowered devices (which are doomed to extinction or
obsolescence), I don't get the need for XML. At the end of the day,
the *application* of XML is what is the most important thing, and
precisely the thing that sucks the most cycles from a CPU. The
syntax is the least of it...



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



From gtn at ebt.com  Sat Nov 27 23:27:46 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
In-Reply-To: <006101bf38f7$df579600$98d18dce@sagus.com>
Message-ID: <001301bf392e$6ad731f0$fad45dc7@ebt.com>

> My experience with the DOM WG *and* my recent day jobs  is
> similar -- the least useful parts of XML cause the most work for people
> supporting it. Both CDATA sections and external parsed entities caused
> *massive* amounts of work and contention for us in devising the DOM API.

Sure, so what? I was part of those battles, and I don't see the relevance.

Come up with some use cases where XML simply *cannot* be deployed in a
handheld device, and SML could, and I might even start to see the point
of SML. I'd be more convinced if you projected the technological trends
over a year or two, and could still have the same use-case a year from
today.



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



From gtn at ebt.com  Sat Nov 27 23:38:29 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Forget SML. We need RTSML.
In-Reply-To: <NBBBICMNIPCICMKJECCBMEIBDCAA.jelks@jelks.nu>
Message-ID: <001601bf392f$e91f4510$fad45dc7@ebt.com>

> 	document ::= StartTag Stuff EndTag
> 	StartTag ::= ?<? Tag ?>?
> 	EndTag   ::= ?</? Tag ?>?
> 	Tag      ::= [0-'~']+
> 	Stuff    ::= [0-'~']*
>
> We expect RTSML 1.0 to be a WFeCes Recommendation on April 1,
> 1999 or day after tomorrow (whichever comes first).

This is close to what Rick was talking about. A truly minimal
language:

   content = (char | element)*
   element = '<' [a-zA-Z_]+ '>' content '</' [a-zA-Z_]+ '>'
   char    = [^<]

though "char" would probably be all ASCII characters above
character code 31, minus the less-than sign.







xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 27 23:46:16 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:49 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <3.0.32.19991127154155.014d3100@pop.intergate.ca>

At 07:40 AM 11/27/99 -0500, rev-bob@gotc.com wrote:

>Oh, to swipe a bone from the SML threads, here's another thing to toss in.  
>I have a hard 
>time visualizing radical internationalization on a tiny screen.  Anglo-
>centric characters, I 
>get.  Asian scripts and Cyrillic...well, those seem a bit out of range.  
>Again, am I missing 
>something?  

Yes.  Approximately 75% of the world's population. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 00:01:32 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:17:49 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
	(ricko@allette.com.au)
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <199911272352.RAA00979@bruno.techno.com>


<notice>If the following makes you laugh, that's OK with me.</notice>

Everything inside a start tag declares attribute values, including the
tag name.  The tag name is accurately regarded as the value of the
element's one and only nameless attribute.  Every element must have a
value for its nameless attribute -- even SML elements.

The value of the nameless attribute (the "tag name" or "generic
identifier") is only minimally constrained; it can be can be almost
any token, and its value can be used for any application-defined
purpose whatsoever.

Therefore, if anyone thinks SML can be made to work entirely without
attributes, they should think again.  Attributes are of the essence of
markup, and you can't get rid of them entirely.  Since we can't get
rid of them entirely, where should SML draw the line, and why?
Personally, I'm not easily persuaded that parsing an "=" sign is so
very difficult that it deserves to be discarded in the name of
simplicity.

If you really want simplicity, why not make *all* the attribute names
explicit, instead of exempting only the generic identifier ("GI").  I
mean, for example:

   <sml:GI="z">      instead of     <z>

Then it's simpler to process:

   <sml:GI="z" id="z1">

than it is to process:

   <z id="z1">

 ...because everything that's space-delimited in a start tag is parsed
in exactly the same way.  Furthermore, we no longer care about the
placement, within the start tag, of the generic identifier, because

   <id="z1" sml:GI="z">Hello, simple world!</sgml:GI="z">

can be a perfectly valid start tag for a z element.  That's simpler,
right?

Finally, it's now possible to have an element with no tag name:

   <id="z1">Hello, simple world!</>

If we don't require DTDs anyway, what's the difference?  There is
no reason to say what kind of a thing a particular element is, if you
don't really care what kind of a thing it is, but you merely want to
say something about it that is completely application-defined.

If that's the case, then it's perfectly reasonable to have completely
empty start tags, simply because you have nothing whatsoever to say
about an element, other than that it starts in a certain place:

   <>Hello, simple world!</>

In fact, we can express complete documents with no semantic baggage
whatsoever in their markup.  Now *that's* simplicity!

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954  <<-- new phone number
fax    +1 972 517 4571  <<-- new fax number
pager (150 characters max): srn-page@techno.com

Suite 211               <<-- new address
7101 Chase Oaks Boulevard 
Plano, Texas 75025 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Sun Nov 28 01:05:02 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:49 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
References: <001301bf392e$6ad731f0$fad45dc7@ebt.com>
Message-ID: <001701bf393c$9a2992a0$0ef8fea9@mcc>


----- Original Message -----
From: Gavin Thomas Nicol <gtn@ebt.com>
To: <xml-dev@ic.ac.uk>
Sent: Saturday, November 27, 1999 6:23 PM
Subject: RE: Use cases for XML failure (was Re: #2 Re: [SML] Whether to
support Attribute or not?)


> > My experience with the DOM WG *and* my recent day jobs  is
> > similar -- the least useful parts of XML cause the most work for people
> > supporting it. Both CDATA sections and external parsed entities caused
> > *massive* amounts of work and contention for us in devising the DOM API.
>
> Sure, so what? I was part of those battles, and I don't see the relevance.

There are two basic rationales for "SML" that we've discussed here:

1 - XML is bloated with features that make compliant parsers too bulky
and/or slow for handheld devices.  I'll admit that I'm less enamored of this
argument than when we started a couple of weeks ago, for roughly the reasons
that Gavin has mentioned in other posts.

2- XML is bloated with kludgy stuff that serves no real purpose except for
traditional SGML-like text processing applications,  making it unnecessarily
hard to learn and implement, and ultimately fragile to build upon.  I must
say that I'm becoming more enamored of this argument as we go along.

The relevance of my DOM ranting was to point 2 -- XML-related specs and
tools are unnecessarily complicated and delayed by the need to support the
least generally useful bits of the core spec


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



From devenoges at webfair.com  Sun Nov 28 01:28:00 1999
From: devenoges at webfair.com (Christopher Devenoges)
Date: Mon Jun  7 17:17:49 2004
Subject: SAX (java) endElement event
Message-ID: <3840862C.93CBA7F4@webfair.com>


Is there a way to diferenciate between 
<exampletag/> and <exampletag></exampletag>  when the endElement event
is receaved using SAX?

Simple question, i hope there is a simple answer?

regards
christoph devenoges
developer - webfair.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 01:38:57 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:49 2004
Subject: SAX (java) endElement event
In-Reply-To: <3840862C.93CBA7F4@webfair.com> from "Christopher Devenoges" at Nov 28, 99 02:32:28 am
Message-ID: <199911280238.VAA08988@locke.ccil.org>

Christopher Devenoges scripsit:

> Is there a way to diferenciate between 
> <exampletag/> and <exampletag></exampletag>  when the endElement event
> is receaved using SAX?

Simple answer: no, deliberately so.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 01:53:13 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:49 2004
Subject: [SML] Whether to support Attribute or not?
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
 <199911272352.RAA00979@bruno.techno.com>
Message-ID: <009d01bf3943$8576a300$5df5c13f@PaulTchistopolskii>

 
> <notice>If the following makes you laugh, that's OK with me.</notice>
> 
> Everything inside a start tag declares attribute values, including the
> tag name.  The tag name is accurately regarded as the value of the
> element's one and only nameless attribute.  Every element must have a
> value for its nameless attribute -- even SML elements.
> 
> The value of the nameless attribute (the "tag name" or "generic
> identifier") is only minimally constrained; it can be can be almost
> any token, and its value can be used for any application-defined
> purpose whatsoever.
> 
> Therefore, if anyone thinks SML can be made to work entirely without
> attributes, they should think again.  Attributes are of the essence of
> markup, and you can't get rid of them entirely.  

Why? 

> Since we can't get rid of them entirely, where should SML draw the line, 
> and why?

Because avoiding the difference between attributes and elements 
simplifyes the addressing and *every* realted API ( Xpath, Xslt, DOM, 
XQL e t.c. )  a *lot*  + it  avoids 'multiple levels of encoding' problems e t.c. 

> Personally, I'm not easily persuaded that parsing an "=" sign is so
> very difficult that it deserves to be discarded in the name of
> simplicity.

This is not a problem. The problem is on the next level of 
framework, when we should care about attributes/elements.
 
Rgds.Paul.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 01:55:57 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:49 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <Pine.GSU.4.10.9911271229501.24101-100000@netcom6.netcom.com>
Message-ID: <000601bf3944$0d8d8100$099918d1@docuverse1>

>On Sat, 27 Nov 1999, Don Park wrote:
>> What is the reason for special treatment of ']]>' in
>> character data?
>
>See the third paragraph of Section 2.4 of the Recommendation.  
>It's there
>for compatibility, i.e. so an SGML processor can parse an XML document.

Hmm, I see now.  The relevant sentence is: "The right angle
bracket (>) MAY be represented using the string "&gt;", and
MUST, for compatibility, be escaped using "&gt;" or a
character reference when it appears in the string "]]>" in
content, when that string is not marking the end of a CDATA
section."

'for compatibility' is defined as: "A feature of XML included
solely to ensure that XML remains compatible with SGML."

I think it is fairly safe to say that SML will not be
compatible with SGML.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 02:08:19 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:49 2004
Subject: About SML and internationalization
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAIEMNEHAA.martind@netfolder.com> from "Didier PH Martin" at Nov 27, 99 03:55:28 pm
Message-ID: <199911280308.WAA09570@locke.ccil.org>

Didier PH Martin scripsit:
> 
> Hi John,
> 
> Thanks for correcting my comment about the Eskimo words for snow (and I
> learned something useful in the process, so many thanks for this).

I'm glad; I have dedicated myself to stamping out this many-words-for-snow
meme where I find it.

> This nonetheless, do not diminish the fact that for an Eskimo to be able to
> markup in its own language is a minimal right and respect from the rest of
> the planet toward its own culture. Also, that XML is a framework used to
> create domain languages. Am right this time?

I absolutely agree.

> And as such, a domain language
> may equally well created in Japanese, Chinese, German, English, Spanish,
> Portuguese, French, Russian, Norwegian, Swedish, Danish... By the way (I do
> not want to make an error this time) how many different languages do we have
> on our spaceship named earth?

About 6000, depending on how you define "language" and your criterion
for being a dead language (perhaps 20% are at least moribund if not actually
dead).  Unbelievably, about 1000 languages are found solely on the island
of New Guinea, which occupies less than 1% of the Earth's land area.

See http://www.sil.org/ethnologue for details.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Sun Nov 28 02:06:19 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:49 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
In-Reply-To: <001701bf393c$9a2992a0$0ef8fea9@mcc>
Message-ID: <000901bf3944$a320d320$f5d45dc7@ebt.com>

> 2- XML is bloated with kludgy stuff that serves no real
> purpose except for traditional SGML-like text processing applications,
making
> it unnecessarily hard to learn and implement, and ultimately fragile to
build
> upon.  I must say that I'm becoming more enamored of this argument as we
go along.
>
> The relevance of my DOM ranting was to point 2 -- XML-related
> specs and tools are unnecessarily complicated and delayed by the need
> to support the least generally useful bits of the core spec

In as far as that goes, I'll agree: some parts of XML are unnecessarily
complicated for certain applications... and I'll admit to arguing strongly
for some of these things (in fact, both CDATA and entities). Still,
this "unecessary complication" is only so for certain application domains,
and I don't see them as leading to the necessity for something like
SML.

Rick's post may have been interpreted as somewhat specious... but he is
correct: without any good use cases that *prove* the necessity for SML,
and that set the requirements for it, SML is just an effort in removing
features from XML... the ultimate result of which is likely to not be
too far removed from s-expressions with angle brackets.

Personally, I'd love to hear from some of the phone companies. I'm sure they
would never claim that in a year, new mobile devices will still be so
limited that XML support is out of the question. If they *could* make
such a case, I'd be more than willing to think about things again.

FWIW. Mike, I hope you know that at heart I'm as much of a minimalist
as you are.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 02:11:51 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000601bf3944$0d8d8100$099918d1@docuverse1> from "Don Park" at Nov 27, 99 05:58:14 pm
Message-ID: <199911280311.WAA09647@locke.ccil.org>

Don Park scripsit:

> Hmm, I see now.  The relevant sentence is: "The right angle
> bracket (>) MAY be represented using the string "&gt;", and
> MUST, for compatibility, be escaped using "&gt;" or a
> character reference when it appears in the string "]]>" in
> content, when that string is not marking the end of a CDATA
> section."

What was the SGML reason for forbidding ]]> in parsed character data?

> 'for compatibility' is defined as: "A feature of XML included
> solely to ensure that XML remains compatible with SGML."
> 
> I think it is fairly safe to say that SML will not be
> compatible with SGML.

Well, surely there will be some escape for < provided in SML.
Suppose it is &lt;, which is both XML and HTML.  In that case,
it wouldn't be much brain strain to require &gt; for >, thus
retaining XML-compatibility.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 02:19:55 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:50 2004
Subject: SAX (java) endElement event
References: <199911280238.VAA08988@locke.ccil.org>
Message-ID: <00b701bf3947$43401e40$5df5c13f@PaulTchistopolskii>



SAX is consistent here. "If there is no difference in semantics -
both constructions are equal".

As I was told when discussing my problems with the ignoreable
whitespace outside the root element and <?xml header
( both have "no semantics" - so there is no way to get information
about it with SAX ( and DOM )  and even with XML parser itself ...)  -

'what you are doing is not the XML mainstream'.

If you are interested in receiving such a subtile information
about the *real* situation in XML document  - you point of view
on *what*  is XML document  is *different*  from
'XML mainstream'.

I don't know what is XML mainstream, but it for sure exists. ;-)

With my problems of such kind ( with ignorable whitespace )
I decided to use the "XML mainstream" and then if my client
will  try to kill me because their point of view on what is
XML document will also be different from 'XML mainstream' -
I'l apply my patches to the parser.  If you realy want to
keep that <B/> ( but not to turn it into <B></B>) - I suggest you'l
hack the particilar XML parser.

For example, providing isShorthand  ( or IsActualyKludge )
parameter to endElement() or to start Element()  - it would be
easier than to dance around SAX API and because
this <B></B> and <B/> problem is *not* the only one of
this kind it means that after some time you may get  some
other questions of this kind ;-)

Rgds.Paul.

> Christopher Devenoges scripsit:
>
> > Is there a way to diferenciate between
> > <exampletag/> and <exampletag></exampletag>  when the endElement event
> > is receaved using SAX?
>
> Simple answer: no, deliberately so.
>
> --
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 02:24:13 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:50 2004
Subject: SAX (java) endElement event
In-Reply-To: <00b701bf3947$43401e40$5df5c13f@PaulTchistopolskii> from "Paul Tchistopolskii" at Nov 27, 99 06:21:21 pm
Message-ID: <199911280324.WAA10011@locke.ccil.org>

Paul Tchistopolskii scripsit:

> I don't know what is XML mainstream, but it for sure exists. ;-)

You bet.  See http://www.w3.org/TR/WD-infoset.html for a *preliminary*
view of what is, and what is not, the first-level semantics of an XML
document.  This is not yet official W3 doctrine, but some version of it
will become so.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 03:01:00 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:50 2004
Subject: About sml and internationalization
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAGEMOEHAA.martind@netfolder.com>
Message-ID: <000701bf394d$229ddfa0$099918d1@docuverse1>

I do not know where this confusion is seeping in from.
SML does support i18n.  I introduced English-only
tag names to SEE what people thought and not because
I was convinced that it was the only way to go.

I must also remind you that SML is still in the
explorative stage to see what may be cut out and
what must remain.  There is no need to huff and
puff.

There is also no need to talk down to me from a
high horse about the problems of some lost tribe
in Mongolia.  I have lived long enough to have
my own opinions about such things and I doubt
we will ever convinced each other about what
the 'right' thing to do is.

And, please, be brief and to the point.  We are
all intelligent and knowledgable people here and
just a hint will get the message across.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 03:01:01 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:50 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
In-Reply-To: <001301bf392e$6ad731f0$fad45dc7@ebt.com>
Message-ID: <000801bf394d$23bb3680$099918d1@docuverse1>

>> My experience with the DOM WG *and* my recent day jobs  is
>> similar -- the least useful parts of XML cause the most work 
>for people
>> supporting it. Both CDATA sections and external parsed 
>entities caused
>> *massive* amounts of work and contention for us in devising 
>the DOM API.
>
>Sure, so what? I was part of those battles, and I don't see 
>the relevance.
>
>Come up with some use cases where XML simply *cannot* be deployed in a
>handheld device, and SML could, and I might even start to see the point
>of SML. I'd be more convinced if you projected the technological trends
>over a year or two, and could still have the same use-case a year from
>today.

Gavin,

I was part of those battles too and I agree entirely with
Michael.  DOM got the nasty-end of the stick because of
arcane features of XML and others (i.e. namespace spec).

SML is not about doing what XML *cannot*.  SML is about
creating an ideal tool.  We are not asking people to cut
steak with a fork so please let the knife and the fork
lie side-by-side.

We can gang up on the 'spoon' and 'chopstick' folks
later. <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 03:08:20 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280311.WAA09647@locke.ccil.org>
Message-ID: <000901bf394e$2d01fac0$099918d1@docuverse1>

>Well, surely there will be some escape for < provided in SML.
>Suppose it is &lt;, which is both XML and HTML.  In that case,
>it wouldn't be much brain strain to require &gt; for >, thus
>retaining XML-compatibility.

Yes it is &lt; in SML.  It is not the support of &gt; that is
expensive.  It is the fact that every conforming SML processor
will have to make sure there is no ']]>' in content and issue
error if there is.  This is nonsense from SML point of view.
I would rather support full i18n over this.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 03:13:54 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:50 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether
  to support Attribute or not?)
In-Reply-To: <001301bf392e$6ad731f0$fad45dc7@ebt.com>
References: <006101bf38f7$df579600$98d18dce@sagus.com>
Message-ID: <199911280313.TAA11472@avocet.prod.itd.earthlink.net>

At 06:23 PM 11/27/1999 -0500, Gavin Thomas Nicol wrote:
>[...]
>Come up with some use cases where XML simply *cannot* be deployed in a
>handheld device [...]

I don't think functionality is the issue.  The issue is
complexity, and complexity always comes at a price.

My primary issues with XML have to do with its focus
on markup for publishing.  We use XML for data, and
the XML spec forces XML-for-data engines to support
XML-for-publishing requirements (eg. entities).  We
might do better focusing on data requirements and
calling the language Data Markup Language (DML).

Even so, Jon Bosak and the other initiators of XML
are to be highly commended for creating a technology
whose applicability reached far beyond its original
intent, even if it isn't always a perfect match.

If XML were truly a simple markup language, there
would be little need for engineers to seek out someone
else's parser in order to work with XML; writing the 
parser would be trivial.  I have written an XML parser
and know that doing so is a long and laborous task.
And when you're done it takes countless tests to make
sure you're truly compliant, and non-compliance issues
always seem to pop up.  XML is not simple.

One might argue that once XML parsers are a commodity
(as they are today, except for high performance parse
tree generators), the simplicity of implementation
becomes moot.  Nothing could be further from the truth.
I am forever answering questions for our employees and
our customers about why you have to do certain things
and about why you cannot do others.  This is a huge
waste of everybody's time; it shouldn't be that hard.

Often of these complexities arise again when we design
technologies that work with XML.  Uh oh, attribute
names and element type names are in different spaces,
how do we represent two spaces and how do we address
them?  Uh oh, entity references are legitimate parts
of a document, and sometimes people may need to work
with them as a unit, so how do we give access to both
the logical and physical representations.  (Uh oh, an
argument has just erupted on which pieces are logical
and which physical and whether there really is a
distinction at all.)  Uh oh, I have to attach a value
to a label, but I'm not sure whether to use content
or an attribute value; I'll read up on the issue and
ask our XML guru -- drats, all that research didn't
help.  Uh oh, these documents have CDATA sections are
distinct children of the same parent element, and I
don't know whether they must be distinctly addressable.
Uh oh, I didn't realize that attributes are normalized;
now I have to redesign my DTD using elements.  Uh oh,
this element contains mixed content, and I'm not sure
which semantic labels, if any, apply to the text.

(I would argue against allowing mixed content in DML;
whitespace would be used only for pretty printing.)


--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 03:18:01 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000601bf3944$0d8d8100$099918d1@docuverse1>
References: <Pine.GSU.4.10.9911271229501.24101-100000@netcom6.netcom.com>
Message-ID: <199911280317.TAA12663@avocet.prod.itd.earthlink.net>

At 05:58 PM 11/27/1999 -0800, Don Park wrote:
>[...]
>I think it is fairly safe to say that SML will not be
>compatible with SGML.

XML parsers are supposed to reject such documents as
ill-formed.  Do we want all wellformed SML to be
wellformed XML?  We have to decide on the requirement.

I'd rather not move technology forward by forever
remaining compatible with previous technology.  If
we lived by this constraint we'd still be using DOS.

But XML is already out there and these problems are
already quite rampant.  If SML/DML (my proposed name
and focus Data Markup Language) is to have any chance
of picking up steam, it will have to start out by being
compatible with existing XML engines.  This is not a
technical issue, it's a pragmatic one.

I think we can get the best of both worlds if we allow
']]>' in SML/DML, but the spec should state that for
compatibility with XML one should express this sequence
as ']]&gt;'.  Escaping should not be required, though.

This would mandate that something external to a document
identify the document as SML/DML or XML.  MIME types
work.  I'd want this distinction anyway, since it would
allow me to optimize for SML/DML when I've got it.  The
parsing and internal data structures would simplify,
and GUI could free the user up from XML's oddities.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 03:23:39 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000901bf394e$2d01fac0$099918d1@docuverse1> from "Don Park" at Nov 27, 99 07:10:38 pm
Message-ID: <199911280423.XAA11781@locke.ccil.org>

Don Park scripsit:

> Yes it is &lt; in SML.  It is not the support of &gt; that is
> expensive.  It is the fact that every conforming SML processor
> will have to make sure there is no ']]>' in content and issue
> error if there is.  This is nonsense from SML point of view.

I am suggesting that ">" be forbidden in SML character data altogether.
That way no check for "]]>" is needed at all.  In addition,
all ">"s are guaranteed to be tag terminators, which makes
for a simple inner dispatch loop.

> I would rather support full i18n over this.

The hint you asked for: not doing i18n is asking for trouble
before, during, and after the fact.  Supporting legacy *encodings*
may be unnecessary.  Failing to support the Unicode character set
is plain retrograde.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 03:32:20 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280423.XAA11781@locke.ccil.org>
References: <000901bf394e$2d01fac0$099918d1@docuverse1>
Message-ID: <199911280332.TAA16649@avocet.prod.itd.earthlink.net>

At 11:23 PM 11/27/1999 -0500, John Cowan wrote:
>[...]
>The hint you asked for: not doing i18n is asking for trouble
>before, during, and after the fact.  Supporting legacy *encodings*
>may be unnecessary.  Failing to support the Unicode character set
>is plain retrograde.

I like that.  Say, UTF-8 and UTF-16, both autodetected in the first few bytes, and no chicken-and-egg encoding declarations.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 03:50:41 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:50 2004
Subject: About sml and internationalization
Message-ID: <005901bf3957$3c3bc030$0cf96d8c@NT.JELLIFFE.COM.AU>

 From: Don Park <donpark@docuverse.com>
 
>There is also no need to talk down to me from a
>high horse about the problems of some lost tribe
>in Mongolia.  I have lived long enough to have
>my own opinions about such things and I doubt
>we will ever convinced each other about what
>the 'right' thing to do is.
 
I live and work in Taiwan.  If Chinese names are 
allowed, people here can accept XML (e.g., the Electronic
Government Initiative).  If Chinese encodings 
are allowed (e.g., Big5) people here can use XML. 

So both names and encodings are needed.

According to a post somewhere else (by Murata Makoto
I think), 50% of Japanese XML pages use Japanese
script markup.

Taiwan is the %1 supplier of computer peripherals in
the world and the #11 economic power. Japan is in
the top 3 economic powers. Neither of them are
lost tribes of Mongolia; and, in any case, if the
Mongolians et al. are lost, perhaps it is the result
of us forgetting them.

An element name is not like a keyword in a programming
language.  It is more like a variable name or field name.
These have much more visibility to ordinary users than
keywords in languages. 

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 03:51:53 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280423.XAA11781@locke.ccil.org>
Message-ID: <000001bf3954$3e6f9780$099918d1@docuverse1>

>> Yes it is &lt; in SML.  It is not the support of &gt; that is
>> expensive.  It is the fact that every conforming SML processor
>> will have to make sure there is no ']]>' in content and issue
>> error if there is.  This is nonsense from SML point of view.
>
>I am suggesting that ">" be forbidden in SML character data altogether.
>That way no check for "]]>" is needed at all.  In addition,
>all ">"s are guaranteed to be tag terminators, which makes
>for a simple inner dispatch loop.

Hmm.  Interesting idea.  Low in cost and balances &lt;.

But the problem is now we are incompatible with XML
documents that did not escape &gt; in character data.
The spec used the word 'MAY' for general use and 'MUST'
only when it is used with ]]>.  *head-scratch*

BTW, its only three days more til Joe Stephenson
returns from vacation.  Hang in there folks. <g>

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 03:59:51 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:50 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280317.TAA12663@avocet.prod.itd.earthlink.net>
Message-ID: <000101bf3955$5e9fd640$099918d1@docuverse1>

>I think we can get the best of both worlds if we allow
>']]>' in SML/DML, but the spec should state that for
>compatibility with XML one should express this sequence
>as ']]&gt;'.  Escaping should not be required, though.

How about addressing this issue in a separate guideline
spec for people mixing SML and XML.  This would leave
this rather arcane detail out of the SML spec.

>This would mandate that something external to a document
>identify the document as SML/DML or XML.  MIME types
>work.  I'd want this distinction anyway, since it would
>allow me to optimize for SML/DML when I've got it.  The
>parsing and internal data structures would simplify,
>and GUI could free the user up from XML's oddities.

Aye.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 04:04:12 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000001bf3954$3e6f9780$099918d1@docuverse1> from "Don Park" at Nov 27, 99 07:54:13 pm
Message-ID: <199911280503.AAA13447@locke.ccil.org>

Don Park scripsit:

> Hmm.  Interesting idea.  Low in cost and balances &lt;.
> 
> But the problem is now we are incompatible with XML
> documents that did not escape &gt; in character data.

What of that?  We are incompatible with XML documents that
use PIs, or entities, or attributes.  But SML documents would be
fully compatible with XML processors (modulo the question of
matching _content_ rather than _document_).

With these rules, &lt; &gt; &amp; are the only entity
references and they are all mandatory.  Very simple.
(If we allow legacy encodings, then we need some
kind of character references as well, presumably &#xnnn; .)

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 04:07:08 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:51 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <007801bf3959$91ab52e0$0cf96d8c@NT.JELLIFFE.COM.AU>


From: Pavel Velikhov <pvelikho@cs.ucsd.edu>

 >Rick Jelliffe wrote:
>>
>>
>> From: Pavel Velikhov <pvelikho@cs.ucsd.edu>
>>
>> >If you don't know whether the object you are picking is an
>> >attribute or an element, you will have to write a disjunction.
>>
>> When don't you know whether an object you are picking is an
>> attribute or an element?
>>
>> Rick Jelliffe
>
>When you are querying a collection that does not have a DTD for
>example. You may know that homes have an id, but you don't know
>whether the id is an attribute or a element. Another case is a
>relational->XML wrapper, it export relational attributes as
>XML attributes, but might as well export them as elements.

Isn't your complaint really that there is no standard mapping from
a relational schema to a notional DTD/Schema?  Let alone for
round-tripping.   A policy that said "1 field equals 1 element"
would meet your requirements even in XML ; SML reduces
the choices in one area, but not enough to make querying work
automatically.

Without such a mapping policy, you cannot assume anything about
what is returned by a query.  If the database uses case-sensitive names,
which case is returned for the generic identifier? If the data is stored
as a date, what date format is returned?  If a text field is used, can
that
text field contain markup?

So it would be a standard mapping policy that would fix the problem,
in any markup 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 04:13:07 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:51 2004
Subject: About sml and internationalization
In-Reply-To: <005901bf3957$3c3bc030$0cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000201bf3957$397e9c00$099918d1@docuverse1>

>According to a post somewhere else (by Murata Makoto
>I think), 50% of Japanese XML pages use Japanese
>script markup.

Now, this is really fascinating.  Can you provide some
info on where I might dig to find more on this?  I
will go ahead and search Murata Makoto's message for
now.

>An element name is not like a keyword in a programming
>language.  It is more like a variable name or field name.
>These have much more visibility to ordinary users than
>keywords in languages.

There is some truth in this but I would like to see the
evidence of this line of thinking being used in practice.
I would also like to see if they are doing it for the
right reasons or not.

I do not mind wrong or appearing to be an upright arse
as long as things turn out right in the end.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 04:18:28 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280423.XAA11781@locke.ccil.org>
References: <000901bf394e$2d01fac0$099918d1@docuverse1>
Message-ID: <199911280418.UAA02269@avocet.prod.itd.earthlink.net>

At 11:23 PM 11/27/1999 -0500, John Cowan wrote:
>[...]
>I am suggesting that ">" be forbidden in SML character data altogether. [...]

Eeks.  I worry about readability.  But we've already lost some readability by throwing out '<'.  I like the simplicity, and it intuitively follows from having to escape '<'.

Could minimize user confusion: "But the text already contains 'x > y', so I don't understand why 'x < y' doesn't work."

I'll sign up for this approach.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 04:45:17 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:51 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <199911280445.UAA10606@avocet.prod.itd.earthlink.net>

At 02:41 PM 11/27/1999 +0800, Rick Jelliffe wrote:
>From: Don Park <donpark@docuverse.com> 
>>I believe it is now time to address the question of
>>whether Attribute should be supported in SML or not.
>[...]
>Are you talking about syntax or labelling here?  [...]

Both.  If I ask an element for its date, and there is both an attribute named 'date' and an element type named 'date', I have to know to which I'm referring.  If you mean the element type, then regardless of whether an attribute by that name exists, if no element of that name exists you get nothing.

It's unfortunate that attribute and element names belong to different namespaces.  I wish attributes were merely a syntactic shorthand for giving the values of unstructured elements.  Because they belong to different namespaces, and because they have different canonicalization rules, this cannot be so.

The issue is naming.  The syntactic role of the item necessarily becomes part of the name, since it identifies the missing namespace constituent.

When something external to the document must identify a constituent of the document, it must also indicate whether it refers to the attribute or the element of the given name.  Even the XML namespaces spec gives attributes and elements distinct virtual namespaces within the same XML namespace.

Moreover, if you go from raw data to XML, you have to identify the syntactic role of that data.  Why should we have to carry XML syntax information along with our data?  Absent those syntactic clues, you'll find yourself either shoving all data into element content or shoving all unstructured data into attributes and all structured data into element content.

As before, the issue is complexity.  Every XML application is forced to effectively work with two namespaces for every element: one for the attributes of that element, and one for the child elements.  It's not even possible to partition solutions into a non-namespace aware infrastructure and a namespace-aware superstructure.  It goes to the bone.  The XML namespaces spec formalizes this with its distinction between per-element namespaces and the default namespace; the XML namespaces spec did not introduce these namespaces.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 04:56:09 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280503.AAA13447@locke.ccil.org>
Message-ID: <000001bf395d$3cad5f00$099918d1@docuverse1>

>> But the problem is now we are incompatible with XML
>> documents that did not escape &gt; in character data.
>
>What of that?  We are incompatible with XML documents that
>use PIs, or entities, or attributes.  But SML documents would be
>fully compatible with XML processors (modulo the question of
>matching _content_ rather than _document_).
>
>With these rules, &lt; &gt; &amp; are the only entity
>references and they are all mandatory.  Very simple.
>(If we allow legacy encodings, then we need some
>kind of character references as well, presumably &#xnnn; .)

Well, you convinced me.  I originally wanted to remove
all predefined character entities and rely on just numeric
character entities, but I can live with just &lt;, &gt;,
and &amp;.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Sun Nov 28 05:17:17 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:51 2004
Subject: [SML] Whether to support Attribute or not?
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU><199911272352.RAA00979@bruno.techno.com> <009d01bf3943$8576a300$5df5c13f@PaulTchistopolskii>
Message-ID: <008201bf395f$d7b06040$0ef8fea9@mcc>

>
> Because avoiding the difference between attributes and elements
> simplifyes the addressing and *every* realted API ( Xpath, Xslt, DOM,
> XQL e t.c. )  a *lot*  + it  avoids 'multiple levels of encoding' problems
e t.c.
>

That seems like the best reason to remove attributes from "SML" to me too.

A couple of potential downsides ...

If SML parsers don't recognize attributes, then we can't have an SML-ized
XHTML.  Does anyone care?  How about WML?  I for one would care if WML was
incompatible with SML ...

How about XSLT?  It would be nice if stylesheets to turn SML into something
displayable were themselves parseable as SML.  I'm pretty sure that you
couldn't write a useful XSLT stylesheet without using attributes ....

I'm inclined to allow attributes in SML itself but to have a "non-normative
appendix" that is a fairly integral part of the document explaining that
attributes are supported only for compatibility reasons and discouraging
people from using them in "new" SML applications and outlining the various
attribute-related pitfalls to avoid.

Obviously I'm still open to arguments on either side.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 06:15:21 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:51 2004
Subject: [SML] Whether to support Attribute or not?
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
 <199911272352.RAA00979@bruno.techno.com>
 <009d01bf3943$8576a300$5df5c13f@PaulTchistopolskii>
 <008201bf395f$d7b06040$0ef8fea9@mcc>
Message-ID: <014f01bf3968$1f3f7e20$5df5c13f@PaulTchistopolskii>



> >
> > Because avoiding the difference between attributes and elements
> > simplifyes the addressing and *every* realted API ( Xpath, Xslt, DOM,
> > XQL e t.c. )  a *lot*  + it  avoids 'multiple levels of encoding' problems
> e t.c.
> >
> 
> That seems like the best reason to remove attributes from "SML" to me too.

> A couple of potential downsides ...
> 
> If SML parsers don't recognize attributes, then we can't have an SML-ized
> XHTML.  Does anyone care?  How about WML?  I for one would care if WML was
> incompatible with SML ...

We have a huge 'legacy' problem with attributes. I suggest to solve the 
legacy problems in the way they are solved in general. 

SML <-> XML-format-with-attributes converter, or especial layer e t.c, 
but *not*  the changes to SML layer.

> How about XSLT?  It would be nice if stylesheets to turn SML into something
> displayable were themselves parseable as SML.  I'm pretty sure that you
> couldn't write a useful XSLT stylesheet without using attributes ....

<aside>

S-XSLT should be written anyway. XT will hardly fit into 
cell phone ;-)

S-XSLT processor should be much easier to write than 
it was to write XT ( the same is with SML parser, S-SAX, e t.c.):

    1. All inventions are already in place ;-)
    2. All that is  needed  is 'bugfixing' the existing design 
in some places.
    3. 'Bugfixing'  could often be 'throw away'. 

</aside>

However, at the first step ( on server side ;-) SML files could be 
processed by XSLT processor, because SML is XML  - no 
big problem here.
 
> I'm inclined to allow attributes in SML itself but to have a "non-normative
> appendix" that is a fairly integral part of the document explaining that
> attributes are supported only for compatibility reasons and discouraging
> people from using them in "new" SML applications and outlining the various
> attribute-related pitfalls to avoid.

I think it is bad idea. "We give you this feature but you should not use it".

I think it's better not to give that feature at all, because ... Because it'l 
not force us to write S-XSLT, for example. 

And because I think that it would be always possible to solve some 
legacy problem with especial mapping layer ( using XT, for example ) 
to go from SML to  *ML, like people are doing now,  utilizing some 
SGML tools with XML

At the moment there is simply no solid XML-ish way to render the 
XML documents to different media. I think mostly people are 
utilizing SGML-ish tools for such a task, 'converting' XML to SGML. 

I don't understand why can't we do the same with SML, converting it 
to XML ( with belowed attributes ;-). Should be *very* easy with XT, 
right ?

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 06:43:27 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000001bf395d$3cad5f00$099918d1@docuverse1>
References: <199911280503.AAA13447@locke.ccil.org>
	<000001bf395d$3cad5f00$099918d1@docuverse1>
Message-ID: <14400.49130.470000.734493@menteith.com>

At 27 Nov 1999 20:58 -0800, Don Park wrote:
 > >With these rules, &lt; &gt; &amp; are the only entity
 > >references and they are all mandatory.  Very simple.
 > >(If we allow legacy encodings, then we need some
 > >kind of character references as well, presumably &#xnnn; .)
 > 
 > Well, you convinced me.  I originally wanted to remove
 > all predefined character entities and rely on just numeric
 > character entities, but I can live with just &lt;, &gt;,
 > and &amp;.

Even if you disallow existing encodings so that SML allows only UTF-8
and/or UTF-16, you should still allow numeric character references so
that you can represent any Unicode character even if you're creating
SML data using Windows Notepad.

If you consider that people won't create SML data and that machines
will, then disallow numeric character references.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 07:03:24 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:17:51 2004
Subject: [SML] Preliminary EBNF for SML
In-Reply-To: <001301bf387a$6880cba0$099918d1@docuverse1>
References: <199911261240.MAA24954@nag.co.uk>
	<001301bf387a$6880cba0$099918d1@docuverse1>
Message-ID: <14400.50375.790000.429861@menteith.com>

At 26 Nov 1999 17:20 -0800, Don Park wrote:
 > Internationalization is also less of a problem than you
 > think.  Translating English name to foreign words usually
 > results in a weird words.  Just ask any foreigner with
 > foreign version of Windows if the menu commands made good
 > sense to them when they first started using it.  The fact
 > is that when a person learns how to use computers in non-
 > English speaking countries, they have to learn a whole new
 > set of words consisting of old or uncommon words overloaded
 > with new meanings.
 > 
 > Also, we are going to have a big problem with schema
 > differences in the future and I would rather not have
 > foreign language variations of common tags like <name> and
 > <address> in the pot as well.

Well, it often seems to me that the U.S. is not an English-speaking
country, and compared to English, American spelling shows a lot of
foreign language variations.  When we choose the one, true set of
common tags, it's nice to know we'll have <colour>, not <color>.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Sun Nov 28 08:30:40 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:51 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <199911280330395.SM01048@Unknown.>

> ** Original Sender: Tim Bray <tbray@textuality.com>
> 
> >Oh, to swipe a bone from the SML threads, here's another thing to toss in.  
> >I have a hard time visualizing radical internationalization on a tiny screen.  Anglo-
> >centric characters, I get.  Asian scripts and Cyrillic...well, those seem a bit out of
> >range.  Again, am I missing something?  
> 
> Yes.  Approximately 75% of the world's population. -Tim

No, I meant "Am I missing something about the available screens, so that these visually 
complex glyphs are actually easier to display on them than I currently believe?"  I am 
well aware that there are many people on the globe who use a non-Anglo alphabet; I'm 
just questioning whether current tiny screens are up to the challenge of serving the needs 
of those people.  I just can't visualize squeezing Kanji into an 8x7 pixel matrix.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 08:38:56 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <14400.49130.470000.734493@menteith.com>
Message-ID: <000101bf397c$529222a0$099918d1@docuverse1>

>Even if you disallow existing encodings so that SML allows only UTF-8
>and/or UTF-16, you should still allow numeric character references so
>that you can represent any Unicode character even if you're creating
>SML data using Windows Notepad.
>
>If you consider that people won't create SML data and that machines
>will, then disallow numeric character references.

Tony, numeric character reference is still in.  I was just saying that
predefined character references like &lt;, &gt;, and &amp; are there
for convenience only since numeric character references are there.

Not too many folks noticed it but I removed the hex numerical character
references in the preliminary EBNF.  I prefer hex but didn't like the
extra 'x' to get there.  I can go with either hex or decimal but not
both.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Sun Nov 28 08:58:44 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
Message-ID: <199911280358144.SM01048@Unknown.>

> Not too many folks noticed it but I removed the hex numerical character
> references in the preliminary EBNF.  I prefer hex but didn't like the
> extra 'x' to get there.  I can go with either hex or decimal but not
> both.

Why on earth not?  I hope you're not going to plead processor power or complexity of 
coding; I remember writing this conversion in my sleep on ye olde Apple II, lo these 
many years ago.  Considering that my $100 palmtop has much more memory than even 
my old revved-up Apple clone ever did (and probably more computing power), I just 
can't realistically credit this argument.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 09:17:54 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:51 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280358144.SM01048@Unknown.>
Message-ID: <000201bf3981$ce82b460$099918d1@docuverse1>

>> Not too many folks noticed it but I removed the hex 
>numerical character
>> references in the preliminary EBNF.  I prefer hex but didn't like the
>> extra 'x' to get there.  I can go with either hex or decimal but not
>> both.
>
>Why on earth not?  I hope you're not going to plead processor 
>power or complexity of coding; I remember writing this conversion
>in my sleep on ye olde Apple II, lo these many years ago.
>Considering that my $100 palmtop has much more memory than even 
>my old revved-up Apple clone ever did (and probably more 
>computing power), I just can't realistically credit this argument.

I just do not see the point of offering both hex and decimal.
Convenience doesn't fly since writer might be used to hex and
the reader might be used to decimal.

Unless someone can offer a compelling reason for supporting both,
I am sticking with my view.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 10:11:20 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:51 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <199911272352.RAA00979@bruno.techno.com>
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
 <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <3.0.6.32.19991128094929.009adda0@gpo.iol.ie>

[Steve Newcomb]
>
>The value of the nameless attribute (the "tag name" or "generic
>identifier") is only minimally constrained; it can be can be almost
>any token, and its value can be used for any application-defined
>purpose whatsoever.
>
"Minimially constrained" in Unicode-land is a lot more resource
intensive to police than "minimally constrined" in 7 bit ASCII
land. (But that is beside the point.)

>Therefore, if anyone thinks SML can be made to work entirely without
>attributes, they should think again.

"Therefore"? A non-sequiter surely?

>Attributes are of the essence of
>markup, and you can't get rid of them entirely.  Since we can't get
>rid of them entirely, where should SML draw the line, and why?

Mu. I reject the premise of the question. You have not established
a case for retention of attributes yet you are proceeding to
discuss questions that presuppose you have established a case.

>Personally, I'm not easily persuaded that parsing an "=" sign is so
>very difficult that it deserves to be discarded in the name of
>simplicity.
>

Parsing the "=" sign has nothing to do with it. The problem is
that attribute value literals are second class citizens. As
containers for data they are constrained to carrier bag of
character data and entity references.

>If you really want simplicity, why not make *all* the attribute names
>explicit, instead of exempting only the generic identifier ("GI").

Turn it around for a moment. Think of it this way:
	1) elements are elements
	2) attribute values are kinda-sort elements except that they
	are constrained in various ways.
Simplification:
	1) Make all attributes elements

Expressive power lost = 0

>   <z id="z1">

becomes
	<z><id>z1</id>...

>I mean, for example:
>
>   <sml:GI="z">      instead of     <z>
>
>Then it's simpler to process:
>
>   <sml:GI="z" id="z1">
>
>than it is to process:
>
>   <z id="z1">
>
> ...because everything that's space-delimited in a start tag is parsed
>in exactly the same way.  Furthermore, we no longer care about the
>placement, within the start tag, of the generic identifier, because
>
>   <id="z1" sml:GI="z">Hello, simple world!</sgml:GI="z">
>
>can be a perfectly valid start tag for a z element.  That's simpler,
>right?
>

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 10:11:22 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:51 2004
Subject: RSS and WAP - another RSS question
In-Reply-To: <034001bf390d$3bf56800$1918ccce@murphy>
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie>
 <384018F6.182C7EFC@finetuning.com>
Message-ID: <3.0.6.32.19991128095357.00a13760@gpo.iol.ie>

At 11:25 AM 11/27/99 -0800, Dave Winer wrote:
>Sure, I'll take a stab at it.
>
>See the commercials on TV for wireless phones that double as web browsers?
>
>Not much room in that space. Room for one headline and perhaps a channel
>name.
>
Right. It seems to me that an <abstract> element or something similar
in RSS would be a great benefit. When viewed on a first generation
WAP phone, the user would view the abstract. When viewed on a desktop
browser, the user would also read the abstract but most probably
click through to the full HTML page.
>
>Anyway, I don't know what Sean has in mind, but this seems like a no-brainer
>app for RSS, or something doing pretty much the same thing. (Reinvented
>wheels.)
>
I think that RSS could really jumpstart the content-to-WAP-phone
area. All I want it a teeny-weeny abstract field...

regards,


<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 10:35:52 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:17:52 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000101bf397c$529222a0$099918d1@docuverse1>
References: <14400.49130.470000.734493@menteith.com>
	<000101bf397c$529222a0$099918d1@docuverse1>
Message-ID: <14400.63008.820000.765257@menteith.com>

At 28 Nov 1999 00:41 -0800, Don Park wrote:
 > >Even if you disallow existing encodings so that SML allows only UTF-8
 > >and/or UTF-16, you should still allow numeric character references so
 > >that you can represent any Unicode character even if you're creating
 > >SML data using Windows Notepad.
 > >
 > >If you consider that people won't create SML data and that machines
 > >will, then disallow numeric character references.
 > 
 > Tony, numeric character reference is still in.  I was just saying that
 > predefined character references like &lt;, &gt;, and &amp; are there
 > for convenience only since numeric character references are there.

You did say they were in, but John Cowan suggested they should be out.

 > Not too many folks noticed it but I removed the hex numerical character
 > references in the preliminary EBNF.  I prefer hex but didn't like the
 > extra 'x' to get there.  I can go with either hex or decimal but not
 > both.

Take out the decimal and put back the hexadecimal.  I nearly said as
much in my previous post but I thought it was too obvious to mention.

Just about everything about Unicode characters -- from how the Unicode
Standard refers to them to how most computer languages represent them
-- is in terms of hexadecimal code values.  In my experience, even if
the encoding isn't Unicode, most specifications of character sets and
most ways of working with code values use hexadecimal character
numbers.

The only application that I can think of that absolutely requires
decimal code values instead of hexadecimal is the SGML Declaration
(and I don't think that you're going to surprise us with the SGML
Declaration for SML anytime soon).

Working with hexadecimal code values some of the time and decimal code
values some of the time is a real pain.  When the character set's
documentation uses hexadecimal code values, it's much easier if you
can enter hexadecimal code values in your data.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 10:53:50 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:52 2004
Subject: About sml and internationalization
In-Reply-To: <000701bf394d$229ddfa0$099918d1@docuverse1>
References: <NBBBJPGDLPIHJGEHAKBAGEMOEHAA.martind@netfolder.com>
Message-ID: <3.0.6.32.19991128103545.00a0ab80@gpo.iol.ie>

I am thinking about the issue to with allowing/disallowing
sets of Unicode characters in element type names as per XML
1.0.

If SML has very few special tokens
e.g. "<", "&" and whitespace, what would happen
if any character outside this teeny weeny set is
allowed in an element type name.

I don't know enough about Unicode to say. I am
thinking about the problem of allowing arbitrary
Unicode in element type names yet side-stepping
the parser name validation tables.

regards,


<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 11:12:58 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:52 2004
Subject: [SML] i18n Name support?
Message-ID: <000001bf3991$dd92f4a0$099918d1@docuverse1>

Since there have been some concerns about the name EBNF rule,
I thought the topic deserves a separate thread.

XML's Name production rule is rather hairy.  Just looking at
the production rules for components of Name (BaseChar,
Ideographic, CombiningChar, Digit, Extender)is enough to give
one headaches.  XML parsers I have seen uses the target
platform's Unicode support to deal with it.  I doubt one
can rely on all SML platforms to have such support.

The question is this: do we support i18n names and if so
do we follow the path taken by XML or open it up to make
implementation easier?  By opening it up, I mean excluding
only the reserved characters ('<', '>', '&', etc.) and
whitespace characters.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 11:27:31 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:52 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <14400.63008.820000.765257@menteith.com>
Message-ID: <000201bf3993$e9ad7ce0$099918d1@docuverse1>

>You did say they were in, but John Cowan suggested they should be out.

It is in the EBNF at this point.  John is probably suggesting that
it be taken out although I don't recall him explicitly saying so.
It might be another one of those skipped paragraph problem of mine.

>Take out the decimal and put back the hexadecimal.  I nearly said as
>much in my previous post but I thought it was too obvious to mention.

Another point in favor of hex over decimal is that the Canoncial XML
spec uses hex.  As I said before, I have no preference either way.
I'll switch to hex in the next version of EBNF and see if anyone
screams.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 11:27:34 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:52 2004
Subject: About sml and internationalization
In-Reply-To: <3.0.6.32.19991128103545.00a0ab80@gpo.iol.ie>
Message-ID: <000101bf3993$e8a0eee0$099918d1@docuverse1>

>I am thinking about the issue to with allowing/disallowing
>sets of Unicode characters in element type names as per XML
>1.0.
>
>If SML has very few special tokens
>e.g. "<", "&" and whitespace, what would happen
>if any character outside this teeny weeny set is
>allowed in an element type name.
>
>I don't know enough about Unicode to say. I am
>thinking about the problem of allowing arbitrary
>Unicode in element type names yet side-stepping
>the parser name validation tables.

Looks like we are on the same trail of thought.
I just started a new thread on this very topic.

I am thinking that it might not be a bad idea to
let arbitrary characters in names and use the
SML/XML interoperability guideline document to warn
people away from the illegal XML name characters.
They can use XML parsers to confirm interoperability.

This drops the cost of supporting i18n names fairly
low.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Sun Nov 28 11:47:06 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:52 2004
Subject: Why no ']]>' in CharData?
Message-ID: <199911280646589.SM01048@Unknown.>

> >> Not too many folks noticed it but I removed the hex numerical character
> >> references in the preliminary EBNF.  I prefer hex but didn't like the
> >> extra 'x' to get there.  I can go with either hex or decimal but not both.
> >
> >Why on earth not?  I hope you're not going to plead processor 
> >power or complexity of coding; I remember writing this conversion
> >in my sleep on ye olde Apple II, lo these many years ago.
> >Considering that my $100 palmtop has much more memory than even 
> >my old revved-up Apple clone ever did (and probably more 
> >computing power), I just can't realistically credit this argument.
> 
> I just do not see the point of offering both hex and decimal.
> Convenience doesn't fly since writer might be used to hex and
> the reader might be used to decimal.

Funny - that's exactly why convenience DOES fly.  If I'm used to hex and you're used to 
decimal, doesn't it make sense to allow both?  It's a trivial conversion that makes for a 
lot more ease for users - allowing both is a no-brainer.  After all, this is supposed to be 
"Simple", right?  Simple - as in "use what you know instead of having to learn a new 
base and the new equivalents for common entities"?

I've got a lot of decimal-based entities in my code; what is your compelling reason for 
making me convert all of them to hex in the name of a *Simple* Markup Language?  
Conversely, maybe Joe over there uses a lot of hex-based Unicode entities; why should 
he have to go in and convert 'em to decimal?

> Unless someone can offer a compelling reason for supporting both,
> I am sticking with my view.

I think portability of existing documents should be more than compelling enough.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 11:57:36 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:52 2004
Subject: [SML] Preliminary EBNF v0.2
Message-ID: <000001bf3998$19430ca0$099918d1@docuverse1>

Here is a second cut of SML EBNF, designed to provoke
more active comment from pro-attribute folks as well
as those who want just English tag names.

Major changes are:
1. No attributes
2. No whitespace after name.
3. 'wild' name character set.
4. No '>' in CharData.
5. 'quot' removed and 'gt' added.
6. Numerical character reference is now in hex.
7. S rule is removed.

The NameChar is basically anything except '<', '>', '&',
and whitespace characters.

Note that changes in this version are not necessarily
what SML will end up as.  I am just trying to get more
feedback from folks because when people tend to speak
out more when they dislike something than when they
like something.

-----------------------------------------------------

data ::= (element | CharData | CharCode)*
element ::= StartTag data EndTag | EmptyTag
StartTag ::= '<' Name '>'
EndTag ::= '</' Name '>'
EmptyTag ::= '<' Name '/>'
Name ::= NameChar+
NameChar ::= [^<>&] - (#x20 | #x9 | #xD | #xA)
CharData ::= [^<>&]*
CharCode ::= '&' ('#x' [0-9A-F]+ | 'lt' | 'gt' | 'amp') ';'

-----------------------------------------------------

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 13:08:26 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:52 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <199911280646589.SM01048@Unknown.>
Message-ID: <000001bf39a1$ff8530e0$099918d1@docuverse1>

>I've got a lot of decimal-based entities in my code; what is 
>your compelling reason for making me convert all of them to
>hex in the name of a *Simple* Markup Language?  Conversely,
>maybe Joe over there uses a lot of hex-based Unicode entities;
>why should he have to go in and convert 'em to decimal?

That is a compelling reason except SML, as it is now, requires
at least some conversion/checking to make sure XML documents
conforms to SML.  So there is no extra cost for converting
everything to hex.

Can you think of any other compelling reasons?  I am genuinely
interested.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 14:07:39 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:17:52 2004
Subject: RSS and WAP - another RSS question
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie><384018F6.182C7EFC@finetuning.com> <3.0.6.32.19991128095357.00a13760@gpo.iol.ie>
Message-ID: <043401bf39aa$72cc7a10$1918ccce@murphy>

> All I want it a teeny-weeny abstract field...

Sean, you may not be aware, in RSS 0.91 we added a <description> field. I'm
not sure what you're looking for from an abstract, but this could be it. The
0.91 extensions are fairly widely supported.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Sun Nov 28 14:56:03 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:52 2004
Subject: [SML] Numeric character references (was RE: Why no ']]>' in CharData?)
References: <199911280646589.SM01048@Unknown.>
Message-ID: <00cd01bf39b0$b4359120$0ef8fea9@mcc>


----- Original Message -----
From: <rev-bob@gotc.com>
To: <xml-dev@ic.ac.uk>
Sent: Sunday, November 28, 1999 6:50 AM
Subject: re: RE: RE: Why no ']]>' in CharData?



> > I just do not see the point of offering both hex and decimal.
> > Convenience doesn't fly since writer might be used to hex and
> > the reader might be used to decimal.
>
> Funny - that's exactly why convenience DOES fly.  If I'm used to hex and
you're used to
> decimal, doesn't it make sense to allow both?  It's a trivial conversion
that makes for a
> lot more ease for users - allowing both is a no-brainer

I agree with Don here.  Accomodating the coder's convenience in the language
itself is the first step on the road to another SGML.  A higher level tool
or API can easily handle the conversion, so put it there, not in the parser.


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



From rev-bob at gotc.com  Sun Nov 28 15:12:19 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:52 2004
Subject: Entities - dec, hex, or both?
Message-ID: <199911281012664.SM01048@Unknown.>

> ** Original Subject: RE: RE: RE: Why no ']]>' in CharData?
> ** Original Sender: "Don Park" <donpark@docuverse.com>
>
> >I've got a lot of decimal-based entities in my code; what is 
> >your compelling reason for making me convert all of them to
> >hex in the name of a *Simple* Markup Language?  Conversely,
> >maybe Joe over there uses a lot of hex-based Unicode entities;
> >why should he have to go in and convert 'em to decimal?
> 
> That is a compelling reason except SML, as it is now, requires
> at least some conversion/checking to make sure XML documents
> conforms to SML.  So there is no extra cost for converting
> everything to hex.

For everything that needs to be converted, there is an extra cost attached - either in time 
or money, even both.  Would you argue that all data should be stored as entities because 
"well, you're going to have to convert some stuff anyway"?

> Can you think of any other compelling reasons?  I am genuinely
> interested.

Consider this for a minute.  Supporting hex and decimal numeric entities requires a tiny 
module in the parser, and no added work for the poor schmuck who has to actually 
convert the documents.  OTOH, choosing between hex and decimal saves only a few 
bytes of code in the parser while piling more work on said schmuck.

Which makes more sense - fix it once (in the parser) or fix it millions of times (in 
conversion)?  I say, fix it once - by allowing the full range of numeric bases currently 
allowed in XML and HTML.  Support is trivial, nonsupport is extremely nontrivial - so 
go with support.

(With that said, does anyone actually use octal representations for entities?  I seem to 
recall that it's allowed, but I've never seen it used.)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Sun Nov 28 15:20:49 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:52 2004
Subject: [SML] Numeric character references
Message-ID: <199911281020989.SM01048@Unknown.>

> > > I just do not see the point of offering both hex and decimal.
> > > Convenience doesn't fly since writer might be used to hex and
> > > the reader might be used to decimal.
> >
> > Funny - that's exactly why convenience DOES fly.  If I'm used to hex and you're
> > used to decimal, doesn't it make sense to allow both?  It's a trivial conversion
> > that makes for a lot more ease for users - allowing both is a no-brainer
> 
> I agree with Don here.  Accomodating the coder's convenience in the language
> itself is the first step on the road to another SGML.  A higher level tool
> or API can easily handle the conversion, so put it there, not in the parser.

And here I thought the whole purpose of SML was to make things simpler for the 
*user*, not to make things easier on lazy programmers.  Silly me.

BTW, if you're going to need a higher-level tool or an API, why bother switching from 
XML in the first place?  Just write a tool or an API that has SML's training wheels, and 
tie it to a full-blown XML parser....

I guess what this boils down to for me is that, to represent complex data, you have to 
have some minimum level of complexity somewhere.  You can play the shell game of 
API vs. HLT vs. parser vs. document code all you want, but the complexity has to be 
there somewhere.  Passing something as simple as hex <=> dec conversion over to a 
different component doesn't remove the complexity - it just shuffles it around.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From matthew at praxis.cz  Sun Nov 28 16:15:57 1999
From: matthew at praxis.cz (Matthew Gertner)
Date: Mon Jun  7 17:17:52 2004
Subject: Handheld computers
References: <001101bf392a$605e5db0$fad45dc7@ebt.com>
Message-ID: <384155BC.CA607A25@praxis.cz>

Gavin Thomas Nicol wrote:
> The point here is that standards define minimal interoperabilityt.
> The more standards you have to implement for interoperability, the
> bigger the problem (i.e. you would be creating an XML that was really
> an aggregate of XML+XLink+Xpointer+<whatever>), and that would be
> bigger and harder than XML 1.0.

Where is the interoperability if there are five different ways to do the
same thing? There is strong consensus in the software development world
that adding complexity in layers makes more sense than implementing it
monolithically. There might be a case for keeping ID and IDREF, for
example, as a minimal mechanism for linking inside a document, but many
of the features of XML (notably entities) are pretty complex in their
own right. An architecture that does away with these, significantly
reducing the complexity of implementing "vanilla" XML, and requires
implementation of (say) an additional XLink layer for applications that
need to create references between documents, would seem to me to provide
more, not less interoperability.

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.champion at softwareag-usa.com  Sun Nov 28 16:36:00 1999
From: mike.champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:52 2004
Subject: [SML] Numeric character references
References: <199911281020989.SM01048@Unknown.>
Message-ID: <00ed01bf39be$a6e5a2e0$0ef8fea9@mcc>


----- Original Message -----
From: <rev-bob@gotc.com>
To: <xml-dev@ic.ac.uk>
Sent: Sunday, November 28, 1999 10:24 AM
Subject: re: [SML] Numeric character references


> > Accomodating the coder's convenience in the language
> > itself is the first step on the road to another SGML.  A higher level
tool
> > or API can easily handle the conversion, so put it there, not in the
parser.
>
> And here I thought the whole purpose of SML was to make things simpler for
the
> *user*, not to make things easier on lazy programmers.  Silly me.

It's interesting how many different senses of "simple" keep coming up in
these threads.  I guess I think of  SML  as "minimal" rather than "simple to
use".  So you're right -- SML is not likely to make coding markup "simpler"
for the user who knows the XML spec well.

Minimalism *does* have long-term advantages to the end user because the
tools they use will tend to be less buggy, delivered on time, etc.  More to
the point, the higher-level abstractions and APIs built on top of SML will
be easier to use because they don't have to hide as much underlying
complexity as XML APIs do.

I've also noticed that the term "lazy" keeps coming up to describe
developers who aren't thrilled about implementing the entire XML spec.  I
think of it rather differently ... as some Clint Eastwood character says, "a
man's gotta know his own limitations" (spoken over the corpse of some Bad
Guy, as I recall). Software developers have to rigorously manage complexity
to produce anything that has a prayer of working right anytime soon.
Nobody's mentioned in this thread that David Brownell has found that almost
none of the XML parsers out there are fully conformant to the spec, and
that's not because the developers are lazy or stupid.  A programmer who
understands his/her own limitations and desires to focus on implementing
*well* the subset of XML that delivers the most power is not lazy, IMHO.

>
> Passing something as simple as hex <=> dec conversion over to a
> different component doesn't remove the complexity - it just shuffles it
around.

Again, you're probably right about this simple example, but I still think
"SML"'s support for numeric character references should be kept minimal as a
matter of principle.  As always, if you don't like the principle, SML
probably has little benefit for you anytime soon.  Don's not trying to
convert everyone to the cause, just to establish legitimacy for those who --
for various reasons -- wish to focus on a minimal subset of SML.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 16:38:30 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:52 2004
Subject: RSS and WAP - another RSS question
In-Reply-To: <043401bf39aa$72cc7a10$1918ccce@murphy>
References: <3.0.6.32.19991127171313.00920c80@gpo.iol.ie>
 <384018F6.182C7EFC@finetuning.com>
 <3.0.6.32.19991128095357.00a13760@gpo.iol.ie>
Message-ID: <3.0.6.32.19991128162111.00a0e290@gpo.iol.ie>

[Sean McGrath]
>> All I want it a teeny-weeny abstract field...
>
[Dave Winer]
>Sean, you may not be aware, in RSS 0.91 we added a <description> field. I'm
>not sure what you're looking for from an abstract, but this could be it. The
>0.91 extensions are fairly widely supported.
>
Yes, I've seen the description field but the data I have seen
populating description fields has really fitted into the concept
of an abstract. I don't want to abuse the <description> element
by using it for something it was not intended for.

regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 16:45:26 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:53 2004
Subject: About XML document linkage and Schemas.
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90B7@sohos002.ied-support.net>

Didier PH Martin wrote:
> So, for an XML citizen, to be valid is too restrictive. this 
> is why maybe,
> most of these citizen are choosing to be only "well formed"

Although my point mentioned validity it wasn't about validity. I was
more emphasising that to encourage the re-use of the data - say an
article - you didn't want the meta data within the data. I have my view
of what meta data I need for an article, but you might have your view
for different purposes.

I made similar points recently - maybe on this list or another XML one -
when people were discussing how to mark up poems with two lots of info -
some relating to the structure, such as lines and words, and some
relating to the content, such as metaphors. I said keep the poem intact
and refer to it from a meta data package - that way two the meta data
packages can refer to the same data. If you put the reference to the
meta data into the data itself, then as far as I am concerned it is no
longer meta data - because you have made it an integral part of the
data.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 16:52:15 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:17:53 2004
Subject: Why I Hate Palmtops (was: Re: SGML, XML and SML)
Message-ID: <3.0.32.19991128085225.014bc100@pop.intergate.ca>

At 03:33 AM 11/28/99 -0500, rev-bob@gotc.com wrote:
>> >I have a hard time visualizing radical internationalization on a tiny 
>> >screen.  Anglo-
>> >centric characters, I get.  Asian scripts and Cyrillic...well, those seem 
>> >a bit out of
>> >range.  Again, am I missing something?  
>> 
>> Yes.  Approximately 75% of the world's population. -Tim
>
>No, I meant "Am I missing something about the available screens, so that 
>these visually 
>complex glyphs are actually easier to display on them than I currently 
>believe?"  

In Japan, lots of people use pocket-size electronic organizers, and 
these things seem to have no trouble displaying kanji.  

The Rev has a point though: the difficulty of rendering text properly,
particularly in an internationalized environment, substantially exceeds
the difficulty of parsing XML.  Like, by orders of magnitude.  Draw your
own conclusions. -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 17:34:51 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:53 2004
Subject: Forget SML. We need RTSML.
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90B9@sohos002.ied-support.net>

Jelks,

I don't know why you're missing the obvious point, which is that there
is lot of programming overhead in allowing any tag to be used. It's also
very confusing for beginners. Far better to restrict the language to one
tag:

 	document ::= StartTag Stuff EndTag
 	StartTag ::= '<RTSML>'
 	EndTag   ::= '</RTSML>'

I was wondering why we couldn't have '/' as the end tag, if there is
only one, but I think that would weaken the error-chocking capabilities.

You also said:

> We expect RTSML 1.0 to be a WFeCes Recommendation on April 1, 
> 1999 or day after
> tomorrow (whichever comes first).

I assume this was a typong mistake; you surely mean in the 1st April,
2000?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lindsey at diac.com  Sun Nov 28 17:44:19 1999
From: lindsey at diac.com (William Lindsey)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] Preliminary EBNF v0.2
In-Reply-To: <000001bf3998$19430ca0$099918d1@docuverse1>
Message-ID: <Pine.LNX.4.10.9911281013140.32439-100000@cobra.diac.com>

On Sun, 28 Nov 1999, Don Park wrote:

> The NameChar is basically anything except '<', '>', '&',
> and whitespace characters.

This, of course, breaks compatibility with XML.  A bad idea,
in my opinion.  I'd be much more interested in exploring
the possibility of codifying a restricted subset of XML that
can work with the tools I have (psgml, SAX, XSLT, etc.):

* No marked CDATA
* No external general entities
* No mixed content
* No colons in names ;-)
* A single character encoding

Once you've decided to leave XML compatibility behind, why
not 
 (a) start over from scratch (S-Expressions, null end tags, etc.)
 (b) move this discussion to another forum

Enjoy,
Bill


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 18:54:00 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:53 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000101bf397c$529222a0$099918d1@docuverse1> from "Don Park" at Nov 28, 99 00:41:05 am
Message-ID: <199911281953.OAA15149@locke.ccil.org>

Don Park scripsit:

> Not too many folks noticed it but I removed the hex numerical character
> references in the preliminary EBNF.  I prefer hex but didn't like the
> extra 'x' to get there.  I can go with either hex or decimal but not
> both.

Go with hex only, as Unicode documents all characters in hex only.
But keep the x for cheap backward compatibility.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 19:13:55 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:53 2004
Subject: Entities - dec, hex, or both?
In-Reply-To: <199911281012664.SM01048@Unknown.> from "rev-bob@gotc.com" at Nov 28, 99 10:15:29 am
Message-ID: <199911282013.PAA15709@locke.ccil.org>

rev-bob@gotc.com scripsit:

> (With that said, does anyone actually use octal representations for entities?  I seem to 
> recall that it's allowed, but I've never seen it used.)

It's not allowed. Decimal or hex only.  SGML had only decimal until the
WebSGML update.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 19:18:49 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] SML compatibility with XML. ( Preliminary EBNF v0.2 )
References: <Pine.LNX.4.10.9911281013140.32439-100000@cobra.diac.com>
Message-ID: <002f01bf39d5$a8192260$5df5c13f@PaulTchistopolskii>


> This, of course, breaks compatibility with XML.  A bad idea,
> in my opinion.  I'd be much more interested in exploring
> the possibility of codifying a restricted subset of XML that
> can work with the tools I have (psgml, SAX, XSLT, etc.):

> Once you've decided to leave XML compatibility behind.

I don't think anybody realy wants to avoid XML compability.
As far as I remember, in the original SML posting 
Don was talking about the susbset of XML and 
I think the objective remains the same.  Right ?

By XML compatibility I mean that idealy any SML file 
should  be  processed by existing XML APIs and tools
without any pre/post processing of SML file.

However, if there is some *very* serious reason to 
break this kind of compatibitily, it would be very 
interesting to know why SML should get the feature
that breaks such compatibility  with XML.

Rgds.Paul.




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



From clark.evans at manhattanproject.com  Sun Nov 28 19:44:29 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <014f01bf3968$1f3f7e20$5df5c13f@PaulTchistopolskii>
Message-ID: <Pine.LNX.4.10.9911280241480.30277-100000@cauchy.clarkevans.com>


On Sat, 27 Nov 1999, Paul Tchistopolskii wrote:
> S-XSLT should be written anyway. XT will hardly fit into 
> cell phone ;-)
> 
> S-XSLT processor should be much easier to write than 
> it was to write XT ( the same is with SML parser, S-SAX, e t.c.):

I'm all for this; the SSLT definition should be
stream-only; in otherwords, it should not require 
random access to the entire SML stream.

;) Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 19:54:40 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] SML compatibility with XML. ( Preliminary EBNF v0.2 )
In-Reply-To: <002f01bf39d5$a8192260$5df5c13f@PaulTchistopolskii>
References: <Pine.LNX.4.10.9911281013140.32439-100000@cobra.diac.com>
Message-ID: <3.0.6.32.19991128193724.00a13100@gpo.iol.ie>

[Paul Tchistopolskii <paul@qub.com>]
>
>I don't think anybody realy wants to avoid XML compability.
>As far as I remember, in the original SML posting 
>Don was talking about the susbset of XML and 
>I think the objective remains the same.  Right ?
>

"Subset" is the killer word here. Is means
different things to different people. In
an SML context "simple" also means different
things to different people. Simple for 
programmers, simple for content creators,
etc.

I am particularly fond of the way the word
"subset" has been abused in WAP which has
a JavaScript implementation which is an
"extended subset" of ECMA262. Go figure!

regards,



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 20:06:52 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] i18n Name support?
In-Reply-To: <000001bf3991$dd92f4a0$099918d1@docuverse1> from "Don Park" at Nov 28, 99 03:15:18 am
Message-ID: <199911282106.QAA18174@locke.ccil.org>

Don Park scripsit:

> XML parsers I have seen uses the target
> platform's Unicode support to deal with it.  I doubt one
> can rely on all SML platforms to have such support.

Probably not.  But some parsers use their own tables.
It really isn't too hard: a table of characters valid
at the beginning of a name, and another table of characters
valid anywhere in a name, excluding the ones in the first
table.

The main issue is that if combining characters are allowed
to be first in a name, then they will attach to the <
character instead of standing alone, by Unicode rules.

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 20:25:18 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <00f001bf39e2$339cf620$0cf96d8c@NT.JELLIFFE.COM.AU>

 
 >On Sat, 27 Nov 1999, Paul Tchistopolskii wrote:
>> S-XSLT should be written anyway. XT will hardly fit into 
>> cell phone ;-)
 
It would be interesting to know how much code can be fitted into a
cell-phone.  Does anyone actually know?  

It seems that a cell phone can fit at least a WAP system including a
little ECMAScript interpreter and networking.  There are WAPphones
on sale in HongKong, so they can fit the glyphs for 
3,000-7000 characters too, though perhaps some smarts are used
to squeeze them in by components.  


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From martind at netfolder.com  Sun Nov 28 20:38:04 1999
From: martind at netfolder.com (Didier PH Martin)
Date: Mon Jun  7 17:17:53 2004
Subject: About SML data model and implication for RDBMS to SML mapping
Message-ID: <NBBBJPGDLPIHJGEHAKBAEENMEHAA.martind@netfolder.com>

Hi,

So, if I understand well, by removing attributes from elements we are also
changing the data model (I do not say that it is right or wrong, just try to
see the implications).

In XML, if attributes are added to elements we have the following data
model:

Model 1:
-------
element
   |___ properties collection
   |          |___ attribute 1
   |		  |___ attribute 2
   |
   |___ Data content
   |
   |___ element

Model 2:
--------

element
   |___ attribute 1
   |___ attribute 2
   |___ Data content
   |___ element

The difference between model 1 and 2 is that in model 2 the data content and
the attributes are in fact all assembled into a single "property set" (note:
there is no relation here between the set of properties we are talking here
and SGML property sets). some properties could be single valued of multipled
valued (i.e be a collection - candidate for this: idefs, element). In model
1, we separate the data content from the attribute collection. We added more
elements to re-enforce the collection concept.

In SML, if we remove the attributes from the elements then we have a single
model:

Model:
-----
	element
	   |___ element
	   |___ element
			|___ element


Any designed style sheet engine is therefore dependent on a data model and
if we design a XPath kind of addressing schema, then the choice of the data
model is important.

Relational data base to SML mapping:
------------------------------------

In the XML world, There is two school of tought here:
a) a record is mapped an attribute set
Ex:
  <client name="albert"
	    address="2345 Road Runner Road"
	    City="Los Alamos"
	    State="New Mexico"
	    country="USA"/ >

b) a record is mapped into a hierarchy of elements:
Ex:
	<client>
		<name>albert</name>
		<address>2345 Road Runner Road</address>
		<city>Los Alamos</city>
		<state>New Mexico</state>
		<country>USA</country>
	</client>

Advantage for a Query language to get a structure node:
-------------------------------------------------------
Simple, all contexts of a string based query path would be elements only -
This could reduce the number of entities or number of possible combinaison
for a particular path context.
Also, because in XML there is two possibilities, some prefer would use the
first kind of mapping for RDBMS to XML mapping (i.e. use attributes to map
the records content) and others would prefer the second one (i.e. use only
elements to map the records content) . This, in fact, leads to the
situration that, even if the data is serialized into a single format, it is,
in fact, encoded into two different data models. The advantage to remove
properties is that we have a single model.

Result:
-------
I do not know yet for knowledge encoding type of documents, but for data
encoding and more particularly for RDBMS to SML mapping, we gain, at least
that data would be encoded into a single data model. In XML RDBMS to XML
mapping may be done potentialy with two different data model. This last fact
increases costs.

Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clark.evans at manhattanproject.com  Sun Nov 28 21:21:09 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:53 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <Pine.LNX.4.10.9911280245010.30277-100000@cauchy.clarkevans.com>

On Fri, 26 Nov 1999, Don Park wrote:
> I believe it is now time to address the question of
> whether Attribute should be supported in SML or not.

Summary:

  Attributes cannot be eliminated without 
  providing a suitable replacement.

Discussion:

  The reason why SGML/XML/SML is so powerful is
  that it accurately reflects the dual nature
  of reality.  Code has two aspects -- it is 
  edited as data and run as instructions.

  This pattern is recursive.  Witness yet another
  compiler ("yacc"), it is code which instructs the 
  generation of code.  

  XML is powerful beacuse it recognizes that there are 
  _always_ two simotanenous contexts that must be
  distinguished:  data and markup.  

  Attributes are the result of applying this same 
  pattern recursively on the markup itself.   Thus, a 
  given tag can have instructions (the attribute) and 
  data for those instructions (the attribute's value).   
  
  Attributes therefore, allow a second order approximation
  to the recursive pattern:

                           [Attribute]
                        /               
               [Markup]
            /           \\ 
           /               [Value] 

  [Document]                            
                                    /  [Attribute] 
           \\              [Markup] 
            \\           /          \\ [Value]
               [Content]  
                        \\
                           [Content]   ...
                       

  Unfortunately, as pointed out on this list many, many 
  times -- by having a different syntax, attributes do
  not allow for further recursion.  Thus, there is an
  entire realm of reality which cannot be described 
  using XML, since attributes cannot have children.

  Thus, I really doubt that it is possible to have
  a meaningful markup language without attributes --
  however, finding a recursive replacement would 
  be very good.

  Consider:   
    
    <element att="val"> <content/> </element>

    If attributes were eliminated, this would be mapped to:
    
    <element> <att>val</att> <content/> </element>

  
  Possibility #1:

    Use a hard-coded namespace,

    <element> <attribute:att>val</attribute:att> <content/> </element>
    
  Possibility #2:
   
    Use a marker,

    <element> <$att>val</$att> <content/> </element>

  Possibility #3:

    Use another type of brackets,

    <element> {att}val{/att} <content/> </element>

  Possibility #4:

    Use a divider,

    <element> <att>val</att> <|> <content/> </element>
  

  In any case, replacing the attribute mechanism with
  one that allows for recursion would allow for
  stuff like:

   <para alt="<b>alt</b>"> para </para>

  To be legally expressed (using syntax #4):

   <para> <alt><b>alt</b></alt> <|> para </para>


Hmm.  Thoughts? 

Clark
  

  



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



From gtn at ebt.com  Sun Nov 28 21:35:28 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:53 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
In-Reply-To: <000801bf394d$23bb3680$099918d1@docuverse1>
Message-ID: <000901bf39e7$edd60cc0$0100007f@ebt.com>

> I was part of those battles too and I agree entirely with
> Michael.  DOM got the nasty-end of the stick because of
> arcane features of XML and others (i.e. namespace spec). 

I think that is mostly the nature of a supposedly 
application-independent API, which has to, by nature, be
everything to everyone, and as such, not be ideal for
any particular application. The DOM effort was about the
3rd or 4th document API design that I had a hand in, and
none of the other efforts had fewer problems, even though
one of them had a vastly different syntax and document model.
If the DOM was *slightly* worse, it was only because there
wasn't a shared understanding of what the underlying 
data/information model was, because of the differences in the
backgrounds of the DOM WG efforts (hmm. sounds like SML). 

The fact that there was even reasonable concensus is a 
great success in and of itself, and is a tribute to the 
DOM WG members and, not the least, the chair.

> SML is not about doing what XML *cannot*.  SML is about
> creating an ideal tool.  We are not asking people to cut
> steak with a fork so please let the knife and the fork
> lie side-by-side.

If you are *really* talking about creating an ideal tool,
I cannot see the rationale for taking XML as a starting 
point. Why not a binary format? Why not s-expressions?
Why not any of a myriad other things, like ASN.1? What is
to be gained by using angle brackets? Is it for "familiarity"?

FWIW, I still haven't seen a succint problem statement for 
SML that doesn't include a degree of XML reductionism. 
What are the problems it's *really* trying to address? I'd
be more than happy to help design a truly ideal tool for the
job, if that's really what your trying to do.



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



From gtn at ebt.com  Sun Nov 28 21:35:35 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:53 2004
Subject: About sml and internationalization
In-Reply-To: <005901bf3957$3c3bc030$0cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000b01bf39e7$f0f54e20$0100007f@ebt.com>

> An element name is not like a keyword in a programming
> language.  It is more like a variable name or field name.
> These have much more visibility to ordinary users than
> keywords in languages. 

This is very true. I saw a programming language once that
used Japanese for keywords... even the Japanese folk found it
a bit hard to deal with. Japanese programmers 
(and for that matter, programmers in general) use their 
native language for variable names, even in languages that do
not support their encoding (Japanese programmers use Romanji).
The same is true for markup.


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



From gtn at ebt.com  Sun Nov 28 21:35:36 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <008201bf395f$d7b06040$0ef8fea9@mcc>
Message-ID: <000c01bf39e7$f21479c0$0100007f@ebt.com>

> If SML parsers don't recognize attributes, then we can't have
> an SML-ized XHTML.  Does anyone care?  How about WML?  I for one would
> care if WML was incompatible with SML ...
>
> How about XSLT?  It would be nice if stylesheets to turn SML
> into something displayable were themselves parseable as SML.  I'm pretty
> sure that you couldn't write a useful XSLT stylesheet without using
attributes ....

Now this is the kind of thing I find confusing. Don is saying the SML is
entirely
different from XML, and is designed to solve a different set of problems.
Why
is it that it's never mentioned except in the context of XML, or it's tools?

Again, if SML is designed solely to remove the "complexity" from XML, then
I think it is entirely misguided... there is little ground in performance,
or
hardware restrictions to justify it, and for data interchange, where some
parts of XML *do* complicate things, application conventions would appear to
be more than sufficient... and at far less cost that bifurcating the XML
community
just as we're really starting to see interoperability between tools.

Sorry, but I still haven't seen a convincing rationale for SML...


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



From gtn at ebt.com  Sun Nov 28 21:35:33 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:54 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether to support Attribute or not?)
In-Reply-To: <199911280313.TAA11472@avocet.prod.itd.earthlink.net>
Message-ID: <000a01bf39e7$efc9c670$0100007f@ebt.com>

> >Come up with some use cases where XML simply *cannot* be 
> >deployed in a handheld device [...]
> 
> I don't think functionality is the issue.  The issue is
> complexity, and complexity always comes at a price.
> 
> My primary issues with XML have to do with its focus
> on markup for publishing.  We use XML for data, and
> the XML spec forces XML-for-data engines to support
> XML-for-publishing requirements (eg. entities). 

I think that this is simply not true. It's like saying that
XML forces you to support arbitrary GI's... which is an ideal,
if impossible task. At the end of the day, *every* application
has application-level constraints on the full capabilities
of the underlying XML system. Use of entities, CDATA sections,
etc. can be handled at that level quite effectively.

> If XML were truly a simple markup language, there
> would be little need for engineers to seek out someone
> else's parser in order to work with XML; writing the 
> parser would be trivial.  I have written an XML parser
> and know that doing so is a long and laborous task.

I have also written a parser, and I agree that some of the
edge cases are a pain. That said, XML parsers are, and will
be, commodity items. I very seldom even use my parser now.

> I am forever answering questions for our employees and
> our customers about why you have to do certain things
> and about why you cannot do others.  This is a huge
> waste of everybody's time; it shouldn't be that hard.

So let's flip this around, and say that we used SML. Do you
think you'd have a *large* reduction in the number of questions?
How about s-expressions? If the XML syntax is so vastly 
unsuited/incomprehensible in the problem domain I 
find it hard to believe that a similar syntax would do 
much to help, or that there wouldn't be a better basic
syntax to use/

How many of your customers try to use external entities?



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



From gtn at ebt.com  Sun Nov 28 21:35:41 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Numeric character references
In-Reply-To: <00ed01bf39be$a6e5a2e0$0ef8fea9@mcc>
Message-ID: <000e01bf39e7$f626a6a0$0100007f@ebt.com>

> Minimalism *does* have long-term advantages to the end user
> because the tools they use will tend to be less buggy, delivered on time,
> etc.

There is probably some degree of truth to this, but I'm not sure
it would be orders of magnitude.

> More to the point, the higher-level abstractions and APIs built on
> top of SML will be easier to use because they don't have to hide
> as much underlying complexity as XML APIs do.

I really stronly disgree with this.

The DOM is a good example if a general-purpose/application independent
API. Very complex, with many special cases. In general though, an API,
by definition, is *application* specific. For a given application,
I cannot see why the API needs to reflect the underlying
implementation of the system. For example, I just implemented a
fairly complex security system that has calls like:

   Principal authenticate(String id, String key);

and it has 3 different implementations: one using XML, one using ODBC,
and another using LDAP. From an *application* perspective, these
differences are irrelevant.

You know that I was, and still am, in favor of having an API
other than the DOM which would allow *simpler* optimization for
performance. That doesn't imply the requirement for something like
SML to me though....



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



From gtn at ebt.com  Sun Nov 28 21:35:39 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:54 2004
Subject: Handheld computers
In-Reply-To: <384155BC.CA607A25@praxis.cz>
Message-ID: <000d01bf39e7$f34aafd0$0100007f@ebt.com>

> There might be a case for keeping ID and IDREF, for
> example, as a minimal mechanism for linking inside a
> document, but many of the features of XML (notably
> entities) are pretty complex in their
> own right. An architecture that does away with these, significantly
> reducing the complexity of implementing "vanilla" XML, and requires
> implementation of (say) an additional XLink layer for
> applications that need to create references between documents, would seem
to me
> to provide more, not less interoperability.

Only if people also implement XLink.... and XLink
itself is far from trivial.

In an ideal world, we'd have XML, XSLT, XLink, and maybe a
few others supported in all tools. The reality is that this
will likely never happen.



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



From gtn at ebt.com  Sun Nov 28 21:40:42 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <00f001bf39e2$339cf620$0cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <000f01bf39e8$9db23100$0100007f@ebt.com>

> It seems that a cell phone can fit at least a WAP system including a
> little ECMAScript interpreter and networking.  There are WAPphones
> on sale in HongKong, so they can fit the glyphs for 
> 3,000-7000 characters too, though perhaps some smarts are used
> to squeeze them in by components.  

There was actually a talk about this at one of the Unicode conferences.
They really do have to optimize for size in cellphones... but I think
that is less true for WAPphones, and will certainly become less so
in the future.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 28 21:51:44 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Hardware resources. ( Whether to support Attribute or not?)
References: <00f001bf39e2$339cf620$0cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <00a301bf39eb$0134d280$5df5c13f@PaulTchistopolskii>

 
>  >On Sat, 27 Nov 1999, Paul Tchistopolskii wrote:
> >> S-XSLT should be written anyway. XT will hardly fit into 
> >> cell phone ;-)
>  
> It would be interesting to know how much code can be fitted into a
> cell-phone.  Does anyone actually know?  

It depends.  I suggest not to get concentrated  on the particular 
"cell-phone", but to think about 'some device with low memory'.

Before we got PC - many things ( like compilers, OS e t.c) 
were already in place on big computers.  Then PC appears - 
and we need to calculate memory and use  assembly again.
OK, we have PC. Everything is fine, memory is cheap after 
a years of progress we have UNIX running on PC. Then we got, 
for example,  VeriPhone POS ( to process credit cards ) - and 
we are again in the world of low-level programming with limited 
resources e t.c. 

I think this is endless process, because it was endless before.

Maybe something very important happened and now there is some 
way to be more happy about the future? I don't think so.
   
> It seems that a cell phone can fit at least a WAP system including a
> little ECMAScript interpreter and networking.  There are WAPphones
> on sale in HongKong, so they can fit the glyphs for 
> 3,000-7000 characters too, though perhaps some smarts are used
> to squeeze them in by components.  

But there will always be some device with limited resources.
I don't know why it always happens that programms need 
more resources than hardware could give and I don't 
understand why it should change. I don't know why 
Java VM is not already embedded into every device. 

Maybe hardware vendors have some reason for it ?

Not talking about the history of  Next computer ...  wasn't it 
perfect? ... but too expensive .... I think the same is with any 
hardware, including cell-phone. So there will be for sure 
some cell-phones not running ECMAScript interpreter.

The question is what framework would fit  better into 
'cell-phone'  - XML-based or SML-based. 

I think that because people from that hardware world 
are already implementing the subsets of XML - it 
should be taken into account.

Actualy, getting SML in place may help  *XML*  to get 
better market share.  SML could be kind of  
XML for very-very-very thin clients ;-)

Alfred parser showed that XML parser could be small.
Unfortunately,  *only*  the parser may be not enough.  

I want  XT to run everywhere ;-) 

Rgds.Paul.



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



From clark.evans at manhattanproject.com  Sun Nov 28 22:06:43 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:54 2004
Subject: About SML data model and implication for RDBMS to SML mapping
In-Reply-To: <NBBBJPGDLPIHJGEHAKBAEENMEHAA.martind@netfolder.com>
Message-ID: <Pine.LNX.4.10.9911280449440.30277-100000@cauchy.clarkevans.com>


SML without attributes --> SML requires namespaces.

On Sun, 28 Nov 1999, Didier PH Martin wrote:
> In the XML world, There is two school of tought here:
> a) a record is mapped an attribute set
> Ex:
>   <client name="albert"
> 	    address="2345 Road Runner Road"
> 	    City="Los Alamos"
> 	    State="New Mexico"
> 	    country="USA"/ >
> 
> b) a record is mapped into a hierarchy of elements:
> Ex:
> 	<client>
> 		<name>albert</name>
> 		<address>2345 Road Runner Road</address>
> 		<city>Los Alamos</city>
> 		<state>New Mexico</state>
> 		<country>USA</country>
> 	</client>

Which one you use really depends on the context -- what is
data and what is meta-data.   If I am writing a letter
to a client, I would use the former.  If the XML is a
"new client" form, then you use the latter.

If you are doing a XML <-> RDBMS sync, I use something 
completely different:

  <client modified-date="28-NOV-1999" id="2283834" >
    <name>albert</name>
    <address>2345 Road Runner Road</address>
    <city id="LAL">Los Alamos</city>
    <state id="NM">New Mexico</state>
    <country>USA</country>  
  </client>

Where attribues are used to encode information
specific to my database (i.e. primary keys and
modification dates, etc).

Here the content is the data, what a person
may have filled out in a new client HTML form,
and the attributes are meta-data, the information
which my information system needs for bookkeeping.

...

Thus, it may be smart to eliminate attributes,
as Didier's e-mail provides good detail, however,
there must be a way to seperate the meta-data
from the data.

I suggest that namespace support may do it:

  namespace mcdi == my company's database info
  namespace ctml == client information protocol

  <ctml:client>
    <mcdi:modified-date>28-NOV-1999</mcdi:modified-date>
    <mcdi:id>2283834</mcdi:id>
    <ctml:name>albert</ctml:name>
    <ctml:address>2345 Road Runner Road</ctml:address>
    <ctml:city>Los Alamos<mcdi:id>LAL</mcdi:id></ctml:city>
    <ctml:state>New Mexico<mcdi:id>NM</mcdi:id></ctml:state>
    <ctml:country>USA</ctml:country>
  </ctml:client>                                                         

Actually... I like this... it is quite a bit more clear,
and it allows for recursion inside the meta-data when
needed.  Nice.

Thoughts?

Clark




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



From KenNorth at email.msn.com  Sun Nov 28 22:06:04 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Whether to support Attribute or not?
References: <00f001bf39e2$339cf620$0cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <009901bf39ec$f4d30b40$0b00a8c0@grissom>

Forgot to cc: the xml-dev list:

> It would be interesting to know how much code can be fitted into a
> cell-phone.  Does anyone actually know?
>
> It seems that a cell phone can fit at least a WAP system including a
> little ECMAScript interpreter and networking.

The Samsung phone used in the TECO customer service application includes the
UP.Browser that is licensed by many of the mobile phone manufacturers.
Unwired Planet has been doing a lot of WAP compatibility testing:

http://www.uplanet.co.uk/company/history.html
http://www.uplanet.co.uk/news/Archive1999/011399_20LICENSEES.html
http://www.samsungelectronics.com/mobile/home.html

Qualcomm's smart phones:
http://www.qualcomm.com/phones/products/pdq_phone/techSpecs/0,1341,,00.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jelks at jelks.nu  Sun Nov 28 22:31:04 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:17:54 2004
Subject: Forget SML. We need RTSML.
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90B9@sohos002.ied-support.net>
Message-ID: <NBBBICMNIPCICMKJECCBAEJBDCAA.jelks@jelks.nu>

Mark,

> > We expect RTSML 1.0 to be a WFeCes Recommendation on April 1, 
> > 1999 or day after tomorrow (whichever comes first).
> 
> I assume this was a typong mistake; you surely mean in the 1st April,
> 2000?

There is nothing wrong with my typong.

/Jelks


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Sun Nov 28 23:21:39 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun  7 17:17:54 2004
Subject: Still news
Message-ID: <002601bf39ff$f8ff2e20$788410d2@mmm.tigue.com>

While we're talking news, I think the following will 
be very significant for XML:

http://news.cnet.com/news/0-1005-200-1454205.html

Senate approves slimmed-down digital signature bill 

WASHINGTON--The Senate unanimously approved legislation 
to promote e-commerce by giving contracts signed in a 
digital format the same legal standing as the 
ink-and-paper kind.

-John

Tim Bray wrote:
> XML is the cover story on PC week; coverage effusive 
> even by the standards we've started getting used to.  
> Check out http://www.zdnet.com/pcweek/
>
> -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 23:28:49 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Mapping between SML and XML
In-Reply-To: <014f01bf3968$1f3f7e20$5df5c13f@PaulTchistopolskii>
References: <005a01bf38a2$7e23dc40$42f96d8c@NT.JELLIFFE.COM.AU>
 <199911272352.RAA00979@bruno.techno.com>
 <009d01bf3943$8576a300$5df5c13f@PaulTchistopolskii>
 <008201bf395f$d7b06040$0ef8fea9@mcc>
Message-ID: <199911282328.PAA06515@avocet.prod.itd.earthlink.net>

In the thread "[SML] Whether to support Attribute or not?", Mike Champion identified an important issue: the ability of SML to leverage XML technologies.  Paul Tchistopolskii responded suggesting that we provide a way to map between SML and XML without burdening SML with unnecessary XML features.

Should we make it a requirement that it be possible to map XML into SML?

If so, what features of an XML document shall be mapped?  Are entity references lost?  Boundaries between CDATA sections?  Comments?  PIs?

To what degree should the mapping be reversible?

If we decide that this is a requirement, I suggest we use XML namespaces to make it work.  That would probably mean that SML would define a standard set of namespaces for these extra pieces.  But I wouldn't want SML to give these pieces any semantics in the context of SML; they would only serve to make XML survive passage through an SML engine.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 23:35:14 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.LNX.4.10.9911280245010.30277-100000@cauchy.clarkevans
 .com>
References: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <199911282335.PAA09188@avocet.prod.itd.earthlink.net>

This argument doesn't work for me.  An XML document contains no behavior,
only data.  The XML spec gives you two syntaxes for representing data -- a
short one (attributes) and a long one (element content).  Data can be
structured in one syntax but not in the other.

A better argument for providing a replacement is the (unresolved) need to
map to and from XML.

At 04:21 AM 11/28/1999 -0500, Clark C. Evans wrote:
>On Fri, 26 Nov 1999, Don Park wrote:
>> I believe it is now time to address the question of
>> whether Attribute should be supported in SML or not.
>
>Summary:
>
>  Attributes cannot be eliminated without 
>  providing a suitable replacement.
>
>Discussion:
>
>  The reason why SGML/XML/SML is so powerful is
>  that it accurately reflects the dual nature
>  of reality.  Code has two aspects -- it is 
>  edited as data and run as instructions.
>
>  This pattern is recursive.  Witness yet another
>  compiler ("yacc"), it is code which instructs the 
>  generation of code.  
>
>  XML is powerful beacuse it recognizes that there are 
>  _always_ two simotanenous contexts that must be
>  distinguished:  data and markup.  
>
>  Attributes are the result of applying this same 
>  pattern recursively on the markup itself.   Thus, a 
>  given tag can have instructions (the attribute) and 
>  data for those instructions (the attribute's value).   
>  
>  Attributes therefore, allow a second order approximation
>  to the recursive pattern:
>
>                           [Attribute]
>                        /               
>               [Markup]
>            /           \\ 
>           /               [Value] 
>
>  [Document]                            
>                                    /  [Attribute] 
>           \\              [Markup] 
>            \\           /          \\ [Value]
>               [Content]  
>                        \\
>                           [Content]   ...
>                       
>
>  Unfortunately, as pointed out on this list many, many 
>  times -- by having a different syntax, attributes do
>  not allow for further recursion.  Thus, there is an
>  entire realm of reality which cannot be described 
>  using XML, since attributes cannot have children.
>
>  Thus, I really doubt that it is possible to have
>  a meaningful markup language without attributes --
>  however, finding a recursive replacement would 
>  be very good.
>
>  Consider:   
>    
>    <element att="val"> <content/> </element>
>
>    If attributes were eliminated, this would be mapped to:
>    
>    <element> <att>val</att> <content/> </element>
>
>  
>  Possibility #1:
>
>    Use a hard-coded namespace,
>
>    <element> <attribute:att>val</attribute:att> <content/> </element>
>    
>  Possibility #2:
>   
>    Use a marker,
>
>    <element> <$att>val</$att> <content/> </element>
>
>  Possibility #3:
>
>    Use another type of brackets,
>
>    <element> {att}val{/att} <content/> </element>
>
>  Possibility #4:
>
>    Use a divider,
>
>    <element> <att>val</att> <|> <content/> </element>
>  
>
>  In any case, replacing the attribute mechanism with
>  one that allows for recursion would allow for
>  stuff like:
>
>   <para alt="<b>alt</b>"> para </para>
>
>  To be legally expressed (using syntax #4):
>
>   <para> <alt><b>alt</b></alt> <|> para </para>
>
>
>Hmm.  Thoughts? 
>
>Clark
>  
>
>  
>
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1

>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 23:41:48 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:54 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <000c01bf39e7$f21479c0$0100007f@ebt.com>
References: <008201bf395f$d7b06040$0ef8fea9@mcc>
Message-ID: <199911282341.PAA12071@avocet.prod.itd.earthlink.net>

At 04:13 PM 11/28/1999 -0500, Gavin Thomas Nicol wrote:
>[...]
>Again, if SML is designed solely to remove the "complexity" from XML, then
>I think it is entirely misguided... [...]

Or rather, it is not just technically guided.  Complexity has initial costs
and recurring costs -- learning curves, building apps on top of XML,
time-to-market, revisiting old problems, technical support, software
maintainability, etc.

There are technical issues as well, but nothing that can't be overcome with
extra clock cycles and memory chips (translating to non-recurring costs).
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From robertl1 at home.com  Sun Nov 28 23:46:31 1999
From: robertl1 at home.com (Robert La Quey)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.LNX.4.10.9911280245010.30277-100000@cauchy.clarkevans
 .com>
References: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <3.0.6.32.19991128153926.04183c10@mail.dt1.sdca.home.com>

At 04:21 AM 11/28/99 -0500, you wrote:
>On Fri, 26 Nov 1999, Don Park wrote:
>> I believe it is now time to address the question of
>> whether Attribute should be supported in SML or not.
>
>Summary:
>
>  Attributes cannot be eliminated without 
>  providing a suitable replacement.
>
>Discussion:
>
>  The reason why SGML/XML/SML is so powerful is
>  that it accurately reflects the dual nature
>  of reality.  Code has two aspects -- it is 
>  edited as data and run as instructions.
>
>  This pattern is recursive.  Witness yet another
>  compiler ("yacc"), it is code which instructs the 
>  generation of code.  
>

Now you are starting to cook. The only way to model reality 
is to allow the recursion (although it is mostly tail recursion
and could be be converted to iteration) ...

Truncate it if we must but allow it. 

(name, value) is the equivalent of a pointer. Next
SML must allow all possible data structures to be built easily without
arbitrary and artificial interference. Objects and their markup follow. 

This is why I am in favour of SML with no attributes and as 
Didder PH Martin notes a single data model (name,value) or
abstract pointer. The real bang from simplication comes from
simplifying and clarifying the stuff that goes on top. 

Time to move the discussion up a notch in abstraction as
you have done. 

Nice post. 


Bob La Quey

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



From jlapp at webmethods.com  Sun Nov 28 23:47:37 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: Why no ']]>' in CharData?
In-Reply-To: <000001bf39a1$ff8530e0$099918d1@docuverse1>
References: <199911280646589.SM01048@Unknown.>
Message-ID: <199911282347.PAA14614@avocet.prod.itd.earthlink.net>

My vote: at least hex with an x.  I think I would also like
the decimal, just because we're finding that the people who
design XML doctypes are not always programmers.  But given
that a hex code could appear, they'd probably have to be
familiar with hex anyway.  Hmm... having only one way to do
it might also reduce some user confusion.  Always a plus.

At 05:10 AM 11/28/1999 -0800, Don Park wrote:
>>I've got a lot of decimal-based entities in my code; what is 
>>your compelling reason for making me convert all of them to
>>hex in the name of a *Simple* Markup Language?  Conversely,
>>maybe Joe over there uses a lot of hex-based Unicode entities;
>>why should he have to go in and convert 'em to decimal?
>
>That is a compelling reason except SML, as it is now, requires
>at least some conversion/checking to make sure XML documents
>conforms to SML.  So there is no extra cost for converting
>everything to hex.
>
>Can you think of any other compelling reasons?  I am genuinely
>interested.
>
>Best,
>
>Don Park    -   mailto:donpark@docuverse.com
>Docuverse   -   http://www.docuverse.com

--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Sun Nov 28 23:54:59 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] i18n Name support?
In-Reply-To: <199911282106.QAA18174@locke.ccil.org>
References: <000001bf3991$dd92f4a0$099918d1@docuverse1>
Message-ID: <199911282354.PAA17759@avocet.prod.itd.earthlink.net>

At 04:06 PM 11/28/1999 -0500, John Cowan wrote:
>[...]
>The main issue is that if combining characters are allowed
>to be first in a name, then they will attach to the <
>character instead of standing alone, by Unicode rules.

Ah, so that's why.  But why should SML enforce these rules?
Why doesn't Unicode disallow it?  Why did XML go this route?

I'm all for the simplification.  It's hell on performance
to have to make those checks for every character read.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Mon Nov 29 00:06:40 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Preliminary EBNF v0.2
In-Reply-To: <Pine.LNX.4.10.9911281013140.32439-100000@cobra.diac.com>
References: <000001bf3998$19430ca0$099918d1@docuverse1>
Message-ID: <199911290006.QAA23076@avocet.prod.itd.earthlink.net>

I agree in principal with Bill's response, but not with the details.  XML's
complex Unicode subset requirements are unfortunate.  Can any Unicode guru
out there explain the conditions under which someone would put together a
Unicode sequence that XML does not allow?  Such sequences may be invalid
for reasons that SML (and XML) need not enforce; something elsewhere could
enforce them.

However, I would like some form of the first character distinction to
remain in SML element type names.  For this we need merely redefine the XML
Letter production.

(BTW Bill, I think we need colons in names to support XML namespaces,
unless we want to us the name productions found in the namespace spec.)

At 10:43 AM 11/28/1999 -0700, William Lindsey wrote:
>On Sun, 28 Nov 1999, Don Park wrote:
>
>> The NameChar is basically anything except '<', '>', '&',
>> and whitespace characters.
>
>This, of course, breaks compatibility with XML.  A bad idea,
>in my opinion.  I'd be much more interested in exploring
>the possibility of codifying a restricted subset of XML that
>can work with the tools I have (psgml, SAX, XSLT, etc.):
>
>* No marked CDATA
>* No external general entities
>* No mixed content
>* No colons in names ;-)
>* A single character encoding
>
>Once you've decided to leave XML compatibility behind, why
>not 
> (a) start over from scratch (S-Expressions, null end tags, etc.)
> (b) move this discussion to another forum
>
>Enjoy,
>Bill
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Mon Nov 29 00:09:48 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] RE: Forget SML. We need RTSML.
In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E90B9@sohos002.ied-suppor
 t.net>
Message-ID: <199911290009.QAA24435@avocet.prod.itd.earthlink.net>

I don't understand this proposal.  You can't represent structured data with
it.  What am I missing?

At 05:36 PM 11/28/1999 +0000, Mark Birbeck wrote:
>Jelks,
>
>I don't know why you're missing the obvious point, which is that there
>is lot of programming overhead in allowing any tag to be used. It's also
>very confusing for beginners. Far better to restrict the language to one
>tag:
>
> 	document ::= StartTag Stuff EndTag
> 	StartTag ::= '<RTSML>'
> 	EndTag   ::= '</RTSML>'
>
>I was wondering why we couldn't have '/' as the end tag, if there is
>only one, but I think that would weaken the error-chocking capabilities.
>
>You also said:
>
>> We expect RTSML 1.0 to be a WFeCes Recommendation on April 1, 
>> 1999 or day after
>> tomorrow (whichever comes first).
>
>I assume this was a typong mistake; you surely mean in the 1st April,
>2000?
>
>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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 00:16:34 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.LNX.4.10.9911280245010.30277-100000@cauchy.clarkevans.com> from "Clark C. Evans" at Nov 28, 99 04:21:36 am
Message-ID: <199911290116.UAA25524@locke.ccil.org>

Clark C. Evans scripsit:

>   Consider:   
>     
>     <element att="val"> <content/> </element>

How about this?

	<element <att>val</att>> <content/> </element>

This is for sure not XML/SGML, but it generalizes the recursive
pattern.  If you want an attribute on the attribute, you write:

	<element <att <att-of-att>subvalue</att-of-att>>val</att>>  ...

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Mon Nov 29 00:44:19 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.LNX.4.10.9911280245010.30277-100000@cauchy.clarkevans
 .com>
References: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <199911290044.QAA09683@avocet.prod.itd.earthlink.net>

I understand the problem better after reading other people's responses.
What threw me was the analogy to object data and behavior, which I don't
think is the right analogy.

In each of these example elements

  <lineitem><model>XYZ</model><quantity>3</quantity></lineitem>
  <lineitem quantity="3"><model>XYZ</model></lineitem>
  <lineitem quantity="3">XYZ</lineitem>

'lineitem' has two properties: model and quantity.  It happens that in the
last example the model is not labelled 'model'.  The label is missing,
since strictly speaking XYZ is not the lineitem.

If we throw away the quantity attribute we are left with...

  <lineitem>XYZ</lineitem>

XYZ may indeed represent the line item, but we could have chosen a more
specific word...

  <model>XYZ</model>

I'd argue that if an element has attributes in addition to text content,
then the attributes together with the content define the element, and the
content must therefore be yet one more property of the element.  The
property simply has not been named.

You might consider that a shortcoming of XML.  By allowing attributes it
allows elements to have unnamed properties.  I'm having trouble
interpreting this as an advantage that attributes give.  Were there never
attributes, every property would have a label.  (Unless there is mixed
content, which prompts my next thread...)

I think the solution for SML/XML conversion is give this property an
explicit name.

At 04:21 AM 11/28/1999 -0500, Clark C. Evans wrote:
>On Fri, 26 Nov 1999, Don Park wrote:
>> I believe it is now time to address the question of
>> whether Attribute should be supported in SML or not.
>
>Summary:
>
>  Attributes cannot be eliminated without 
>  providing a suitable replacement.
>
>Discussion:
>
>  The reason why SGML/XML/SML is so powerful is
>  that it accurately reflects the dual nature
>  of reality.  Code has two aspects -- it is 
>  edited as data and run as instructions.
>
>  This pattern is recursive.  Witness yet another

>  compiler ("yacc"), it is code which instructs the 
>  generation of code.  
>
>  XML is powerful beacuse it recognizes that there are 
>  _always_ two simotanenous contexts that must be
>  distinguished:  data and markup.  
>
>  Attributes are the result of applying this same 
>  pattern recursively on the markup itself.   Thus, a 
>  given tag can have instructions (the attribute) and 
>  data for those instructions (the attribute's value).   
>  
>  Attributes therefore, allow a second order approximation
>  to the recursive pattern:
>
>                           [Attribute]
>                        /               
>               [Markup]
>            /           \\ 
>           /               [Value] 
>
>  [Document]                            
>                                    /  [Attribute] 
>           \\              [Markup] 
>            \\           /          \\ [Value]
>               [Content]  
>                        \\
>                           [Content]   ...
>                       
>
>  Unfortunately, as pointed out on this list many, many 
>  times -- by having a different syntax, attributes do
>  not allow for further recursion.  Thus, there is an
>  entire realm of reality which cannot be described 
>  using XML, since attributes cannot have children.
>
>  Thus, I really doubt that it is possible to have
>  a meaningful markup language without attributes --
>  however, finding a recursive replacement would 
>  be very good.
>
>  Consider:   
>    
>    <element att="val"> <content/> </element>
>
>    If attributes were eliminated, this would be mapped to:
>    
>    <element> <att>val</att> <content/> </element>
>
>  
>  Possibility #1:
>
>    Use a hard-coded namespace,
>
>    <element> <attribute:att>val</attribute:att> <content/> </element>
>    
>  Possibility #2:
>   
>    Use a marker,
>
>    <element> <$att>val</$att> <content/> </element>
>
>  Possibility #3:
>
>    Use another type of brackets,
>
>    <element> {att}val{/att} <content/> </element>
>
>  Possibility #4:
>
>    Use a divider,
>
>    <element> <att>val</att> <|> <content/> </element>
>  
>
>  In any case, replacing the attribute mechanism with
>  one that allows for recursion would allow for
>  stuff like:
>
>   <para alt="<b>alt</b>"> para </para>
>
>  To be legally expressed (using syntax #4):
>
>   <para> <alt><b>alt</b></alt> <|> para </para>
>
>
>Hmm.  Thoughts? 
>
>Clark
>  
>
>  
>
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1

>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From robin at isogen.com  Mon Nov 29 00:54:38 1999
From: robin at isogen.com (Robin Cover)
Date: Mon Jun  7 17:17:55 2004
Subject: About sml and internationalization
In-Reply-To: <000b01bf39e7$f0f54e20$0100007f@ebt.com>
Message-ID: <Pine.GSO.3.96.991128184156.7204F-100000@grind>


On Sun, 28 Nov 1999, Gavin Thomas Nicol wrote:

> > An element name is not like a keyword in a programming
> > language.  It is more like a variable name or field name.
> > These have much more visibility to ordinary users than
> > keywords in languages. 
> 
> This is very true. I saw a programming language once that
> used Japanese for keywords... even the Japanese folk found it

I don't know Japanese, but I cannot imagine the world being
otherwise, in Japan or in any country in the world.  
XML element type names and attribute names represent
opportunities for users to encode the "name" of a real-world
thing.  The ability to name a thing (see the reflex in dozens
of myths, including the biblical 'naming' of animals) is
widely recognized as an essential privilege and function
within any act of design/creation.  In XML markup design, I suppose
most people would indeed like to be able to nominate a "name"
for a thing in their own language -- not in someone else's
language.  It's just one of the reasons that the TEI provided
a mechanism (using PEs) to allow the redefinition of
all element and attribute names in local languages.

Robin Cover



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



From jlapp at webmethods.com  Mon Nov 29 01:05:24 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Data Markup Language?
Message-ID: <199911290105.RAA22163@avocet.prod.itd.earthlink.net>

Okay, I know this is going to be a hot one.  Please be nice, as I'm only
testing the waters.

Mixed content probably has a place in XML that marks up human-readable
prose, but I have not yet seen it used in my space, where data is
machine-sourced and machine-consumed.  If you're going to give mixed
content to a machine, you'd better assume that the machine won't make sense
of the unlabelled text (or non-explicitly labelled text).  If you want
something to use the data, you better put a label on it.

Given that general entities and comments and such are (possibly) necessary
in the XML-for-publishing space, is it safe for us to assume that SML is
for marked up data only?  Perhaps the use of SML-for-data will so
significantly dwarf the use of SML-for-publishing that maximum benefit can
be gained by excluding the requirements of publishing.

Besides, you could always emulate mixed content such as...

  <x>I'm <evil-term>mixed</evil-term> content.</x>

By writing...

  <x><text>I'm <text><evil-term>mixed</evil-term><text> content.<text></x>

Everything is explicitly labelled.  One additional benefit is that users
would be free to introduce whitespace between elements without worrying
about changing the semantics of the document.

If we decide that SML is for data and not for publishing, should we then
rename SML to Data Markup Language (DML)?  The real answer to this question
depends on the audience that is interested in SML, I think.  So it would
probably be sufficient to refute my suggestion by having a large enough
group of people express interest in SML for publishing.

--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 01:27:30 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Whether to support Attribute or not?
References: <001601bf387c$0a812840$099918d1@docuverse1>
 <199911290044.QAA09683@avocet.prod.itd.earthlink.net>
Message-ID: <011d01bf3a08$ff832f40$5df5c13f@PaulTchistopolskii>


> I understand the problem better after reading other people's responses.
> What threw me was the analogy to object data and behavior, which I don't
> think is the right analogy.
> 
> In each of these example elements
> 
>   <lineitem><model>XYZ</model><quantity>3</quantity></lineitem>
>   <lineitem quantity="3"><model>XYZ</model></lineitem>
>   <lineitem quantity="3">XYZ</lineitem>
> 
> 'lineitem' has two properties: model and quantity.  It happens that in the
> last example the model is not labelled 'model'.  The label is missing,
> since strictly speaking XYZ is not the lineitem.
> 
> If we throw away the quantity attribute we are left with...
> 
>   <lineitem>XYZ</lineitem>
> 
> XYZ may indeed represent the line item, but we could have chosen a more
> specific word...
> 
>   <model>XYZ</model>
> 
> I'd argue that if an element has attributes in addition to text content,
> then the attributes together with the content define the element, and the
> content must therefore be yet one more property of the element.  The
> property simply has not been named.

.... I think, <PCDATA> could be a name of such a  'hidden property' property ? ;-)
 
> You might consider that a shortcoming of XML.  

I don't understand where is a shortcoming here .... I think nobody knows 
for sure what will happen with some 'plain' PCDATA field in the future - it 
may easily become mixed content, so considering PCDATA to be 
a special case of mixed content looks reasonable and consistent to me.

But I agree, when you have PCDATA but  *not*  mixed content it usualy 
means that you'l better to specify some new element / attribute ... 
Do I understand your point ? 

I don't  understand  what to do with such a knowledge ... 

> By allowing attributes it allows elements to have unnamed properties.  
> I'm having trouble interpreting this as an advantage that attributes give.  

> Were there never attributes, every property would have a label.  

> (Unless there is mixed content, which prompts my next thread...)
 
> I think the solution for SML/XML conversion is give this property an
> explicit name.

What is the *problem* you want to solve ?

<lineitem><quantity>3</quantity>XYZ</lineitem> is valid XML and 
valid SML as well.  

Or I'm missing something in SML ?

Or you are saying PCDATA should be restricted from SML, and 
only mixed content should remain?

What is the purpose ? ... Actualy, maybe there is some .... 
 
I don't want to drop mixed content from SML. It will 
kill the markup abilities and I don't see any reasons why 
it should be killed.  Maybe I'm missing something here.

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.Champion at softwareag-usa.com  Mon Nov 29 01:46:18 1999
From: Mike.Champion at softwareag-usa.com (Michael Champion)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Data Markup Language?
References: <199911290105.RAA22163@avocet.prod.itd.earthlink.net>
Message-ID: <005501bf398b$d19518f0$f5beb3c7@WORKGROUP>


----- Original Message -----
From: Joe Lapp <jlapp@webmethods.com>
To: <xml-dev@ic.ac.uk>
Sent: Sunday, November 28, 1999 8:08 PM
Subject: [SML] Data Markup Language?

>
> If we decide that SML is for data and not for publishing, should we then
> rename SML to Data Markup Language (DML)?  The real answer to this
question
> depends on the audience that is interested in SML, I think.  So it would
> probably be sufficient to refute my suggestion by having a large enough
> group of people express interest in SML for publishing

"Data" vs "Publishing" is a reasonable continuum, but it's really hard to
draw boundaries between them that are not very fuzzy.  I'm primarily
interested in "SML" for intelligent messaging to very light clients.  That's
more like "Data", since at least traditionally we're talking about things
like stock quotes, phone numbers, etc. here.... but this has already
branched out into short text messages in the PDA/phone world and we can
imagine it moving more toward "Publishing" as PDA/cellphone screen sizes and
bandwidth improve.

On the other hand, I'm not crazy about "SML" as a name for this, partly
because "simplified" means too many things to too many people.  I'd go for
"Minimal" or even "Skeletal" or "BareBones" (MML? BBML???).  But at this
point, "SML" is a convenient label for this on XML-DEV, and we can worry
about what to call it once we figure out what it IS and who to send it to
for some official blessing.




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



From jlapp at webmethods.com  Mon Nov 29 01:47:44 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:55 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <011d01bf3a08$ff832f40$5df5c13f@PaulTchistopolskii>
References: <001601bf387c$0a812840$099918d1@docuverse1>
 <199911290044.QAA09683@avocet.prod.itd.earthlink.net>
Message-ID: <199911290147.RAA25204@avocet.prod.itd.earthlink.net>

Yes, mixed content is an issue, which is why I started the "Data Markup Language" thread.  You might cast your vote there.

At 05:28 PM 11/28/1999 -0800, Paul Tchistopolskii wrote:
>
>> I understand the problem better after reading other people's responses.
>> What threw me was the analogy to object data and behavior, which I don't
>> think is the right analogy.
>> 
>> In each of these example elements
>> 
>>   <lineitem><model>XYZ</model><quantity>3</quantity></lineitem>
>>   <lineitem quantity="3"><model>XYZ</model></lineitem>
>>   <lineitem quantity="3">XYZ</lineitem>
>> 
>> 'lineitem' has two properties: model and quantity.  It happens that in the
>> last example the model is not labelled 'model'.  The label is missing,
>> since strictly speaking XYZ is not the lineitem.
>> 
>> If we throw away the quantity attribute we are left with...
>> 
>>   <lineitem>XYZ</lineitem>
>> 
>> XYZ may indeed represent the line item, but we could have chosen a more
>> specific word...
>> 
>>   <model>XYZ</model>
>> 
>> I'd argue that if an element has attributes in addition to text content,
>> then the attributes together with the content define the element, and the
>> content must therefore be yet one more property of the element.  The
>> property simply has not been named.
>
>.... I think, <PCDATA> could be a name of such a  'hidden property' property ? ;-)
> 
>> You might consider that a shortcoming of XML.  
>
>I don't understand where is a shortcoming here .... I think nobody knows 
>for sure what will happen with some 'plain' PCDATA field in the future - it 
>may easily become mixed content, so considering PCDATA to be 
>a special case of mixed content looks reasonable and consistent to me.
>
>But I agree, when you have PCDATA but  *not*  mixed content it usualy 
>means that you'l better to specify some new element / attribute ... 
>Do I understand your point ? 
>
>I don't  understand  what to do with such a knowledge ... 
>
>> By allowing attributes it allows elements to have unnamed properties.  
>> I'm having trouble interpreting this as an advantage that attributes give.  
>
>> Were there never attributes, every property would have a label.  
>
>> (Unless there is mixed content, which prompts my next thread...)
> 
>> I think the solution for SML/XML conversion is give this property an
>> explicit name.
>
>What is the *problem* you want to solve ?
>
><lineitem><quantity>3</quantity>XYZ</lineitem> is valid XML and 
>valid SML as well.  
>
>Or I'm missing something in SML ?
>
>Or you are saying PCDATA should be restricted from SML, and 
>only mixed content should remain?
>
>What is the purpose ? ... Actualy, maybe there is some .... 
> 
>I don't want to drop mixed content from SML. It will 
>kill the markup abilities and I don't see any reasons why 
>it should be killed.  Maybe I'm missing something here.
>
>Rgds.Paul.
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 02:08:36 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] SML compatibility with XML. ( Preliminary EBNF v0.2 )
In-Reply-To: <002f01bf39d5$a8192260$5df5c13f@PaulTchistopolskii>
Message-ID: <000601bf3a0e$ff4183a0$099918d1@docuverse1>

I would very very much like to have SML remain compatible with XML so that
SML can be procossed using existing XML tools without any change.

However, unless the cost of i18n name support is reduced much lower,
we can not support it.  I just suggested the first possible solution which
breaks XML compatibility.  This will result in some SML documents
which can not be converted to XML.

<beef>
One other solution might be that we loosen the error-reporting requirement
so that the SML names must follow the same rules as XML names but
checking of invalid characters in SML names is not a well-formed constraint.
</beef>

What do you guys think?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 03:08:42 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:17:56 2004
Subject: Mixed content and whitespace ( [SML] Data Markup Language? )
References: <199911290105.RAA22163@avocet.prod.itd.earthlink.net>
Message-ID: <015701bf3a17$3e9b7ee0$5df5c13f@PaulTchistopolskii>


 
> Besides, you could always emulate mixed content such as...
> 
>   <x>I'm <evil-term>mixed</evil-term> content.</x>
> 
> By writing...
> 
>   <x><text>I'm <text><evil-term>mixed</evil-term><text> content.<text></x>
> 
> Everything is explicitly labelled.  One additional benefit is that users
> would be free to introduce whitespace between elements without worrying
> about changing the semantics of the document.

I see no big difference here, the first one is ( much?) easier to 
write and to read.

What I see is the problem with APIs for  whitespace processing, 
but I think even it is related to mixed context, it is just a part of some 
bigger problem : "how to process whitespace in SML".  The way 
XML does it is a bit inconsistent.

It's  the  can of warms, like namespaces and I'm afraid to 
open any of those by myself ;-)

> If we decide that SML is for data and not for publishing, should we then
> rename SML to Data Markup Language (DML)?  

I think any 'data'  would need to be 'published' earlier or later. 

I think that if we agree on <comment></comment> - 
there is for sure some place for mixed content in 
*any* SML document. I agree - it is not the mainstream.

I would like to be able to create SML documents manualy
and I want it to be as easy as it is now, when I'm creating 
XML documents. Replacing  attributes with elements 
will not make me any big problem. Disabling mixed context 
would make a problem, because I like to use 
<B> </B> ;-)

Even your suggestion simplifies things with whitespace 
processing a bit ( and makes creation of the documents 
a bit harder), I don't think such a subtile improvement
is worth the typing efforts it will cause, but I'm not sure
and if  such a restriction will have some big pozitive 
impact on some other part of the framework - I think 
my personal oppinion may change. At the moment 
I'm against removing <BR/> and I'm against removing 
mixed content. But I was also against removing comments , 
until one nice preson provided the <c> </c> idea.  ;-)

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 03:27:15 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] Mapping between SML and XML
In-Reply-To: <199911282328.PAA06515@avocet.prod.itd.earthlink.net>
Message-ID: <000001bf3a19$f9e52280$099918d1@docuverse1>

>Should we make it a requirement that it be possible to map XML 
>into SML?

Yes.  'possible' is the key word though.  I expect that a
separate spec will introduce some tags to address XML to
SML bridging issues.

>If so, what features of an XML document shall be mapped?  Are 
>entity references lost?  Boundaries between CDATA sections?  
>Comments?  PIs?

One approach is to cover all the XML features in one spec,
basically a catalog of tags mapping to each XML features
with some simple rules on how to create your own set.
This spec should be followed by another spec that
outlines some common sets each addressed to solve
different needs.

>To what degree should the mapping be reversible?

What would prevent the mapping from being non-reversible?

>If we decide that this is a requirement, I suggest we use XML 
>namespaces to make it work.  That would probably mean that SML 
>would define a standard set of namespaces for these extra 
>pieces.  But I wouldn't want SML to give these pieces any 
>semantics in the context of SML; they would only serve to make 
>XML survive passage through an SML engine.

I think one namespace should be enough for XML bridge tag set
unless I missed something.  This is reminiscent of XHTML chaos.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Mon Nov 29 03:38:56 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <199911282341.PAA12071@avocet.prod.itd.earthlink.net>
Message-ID: <001101bf3a1a$9cfa8e10$0100007f@ebt.com>

> >Again, if SML is designed solely to remove the "complexity" 
> from XML, then I think it is entirely misguided... [...]
> 
> Or rather, it is not just technically guided.  Complexity has 
> initial costs and recurring costs -- learning curves, 
> building apps on top of XML, time-to-market, revisiting old 
> problems, technical support, software maintainability, etc.

I don't buy the rationale that a new syntax is needed to address
the problems here. At the end of the day, the people who actually
*use* the systems built around XML should give a tinkers cuss
one way or another... it should be hidden from them.

The XML that is most important is the XML that can't be seen...



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



From jlapp at webmethods.com  Mon Nov 29 05:00:04 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:56 2004
Subject: A call for reason
Message-ID: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>

I'm learning through the grapevine that some people of influence are opposed to the SML effort.  I'm going to argue that provided SML ends up a subset of XML, as it should, the only conflict SML has with XML is the name.  I walk through this step-by-step out of fear that I might leave someone with insufficient information to read between the lines.

I suspect the opposition is very comfortable with the idea that a system might source and consume only documents of a single document type.  XML is after all a metalanguage for creating such document types.

I also suspect that the opposition is very comfortable with the idea that a system might source and consume documents belonging to a finite set of document types.  I could have a finite set of DTDs defining these document types.

But suppose I have a system that sources and consumes only documents whose element type names are expressed in English.  This is not hard to imagine and is probably quite rampant.  But no finite set of DTDs can define this set of documents.  Likewise, no finite set of DTDs can define the set of documents whose element type names are all letters or the set of documents whose elements don't use attributes.  Yet if a system is allowed to select its document types, why can't it select an infinite subset of all possible document types?  What if it's a tool that converts attributes to elements?  Such systems should be allowed.

DTDs are not very expressive, but we can imagine a schema language that specifies where PIs are allowed and where comments are allowed, for example.  XML allows these pieces everywhere, and my system might be able to parse them anywhere, but the higher layers of the system may not recognize them in certain places or may outright reject them.  PIs there would be deceiving in application X, so let's not allow them.  My domain-specific GUI can't represent comments there -- they'll get lost -- so let's not allow them.    Maybe it's a tool for enforcing a way of commenting XML in accordance with company policy.  These constraints happen, and there's no stopping them.  Yes, the XML processor is required to report PIs (and may report comments) to the application, but no application is required to succeed if they are reported.

The XML 1.0 spec allows an application to accept and reject any subset of XML; it only makes demands of the XML processor that the application contains.  I believe this is in full conformance with the spirit of XML as well, as it's only the parsing technology that it strives to make universal.

Yet if the application is going to reject that comment or that PI or that non-English element type name in the end, what difference does it make to the outside world whether it is the parser layer that makes the decision?  Each application in a ring of applications exchanging XML is already beholden to conform to a particular schema or set of schemas, so it's already the business of this ring to decide what constitutes acceptable XML.

Provided that the SML effort yields a subset of XML, as it should, SML should end up being a label for a group of document types -- nothing more.  One may then label an application as SML-compliant.  Rings of SML-compliant applications may surface, but for most uses such rings will be further constrained to a finite set of document types.  If we had a schema language of sufficient richness -- expressing name production rules and general syntactic layout -- we could even use it to express the SML class of document types.

What's wrong with defining classes of XML document types and restricting applications to using XML belonging to these classes?  The notion sounds useful for much more than identifying the set of 'simple' document types.  Is this not reasonable?

And maybe the SML audience can give a little by choosing a name that makes SML sound like a class of XML rather than an alternative to XML.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Mon Nov 29 05:29:55 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <001101bf3a1a$9cfa8e10$0100007f@ebt.com>
References: <199911282341.PAA12071@avocet.prod.itd.earthlink.net>
Message-ID: <199911290529.VAA03669@hawk.prod.itd.earthlink.net>

At 09:20 PM 11/28/1999 -0500, Gavin Thomas Nicol wrote:
>[...]
>The XML that is most important is the XML that can't be seen...

We are finding that just the opposite is true.  Both the technical and the business savvy are designing DTDs, and both the technical and the business savvy fully expect to be able to see the XML.

Ergo, simplicity is extremely important and ideally a requirement.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Mon Nov 29 05:39:20 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] Mapping between SML and XML
In-Reply-To: <000001bf3a19$f9e52280$099918d1@docuverse1>
References: <199911282328.PAA06515@avocet.prod.itd.earthlink.net>
Message-ID: <199911290539.VAA08917@hawk.prod.itd.earthlink.net>

At 07:29 PM 11/28/1999 -0800, Don Park wrote:
>>Should we make it a requirement that it be possible to map XML 
>>into SML?
>[...]
>>To what degree should the mapping be reversible?
>
>What would prevent the mapping from being non-reversible?

Any kind of lossiness.

>[...]
>I think one namespace should be enough for XML bridge tag set
>unless I missed something.  This is reminiscent of XHTML chaos.

I would like to think so.  The following potential requirements worry me:

(a) Mapping should preserve attribute namespaces.
(b) Mapped attributes of XML should be occur as elements in SML.
(c) Attribute namespaces should be represented in SML using XML namespaces.

Reasons for having these requirements follow:

(a) Namespaces are necessary semantic markers.
(b) Attribute values should be addressable in SML without having to first interpret the SML as encoded XML.
(c) We should leverage all existing namespace-aware code (whether in the parser or in the application).
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From narasimha.ayyagari at mciworld.com  Mon Nov 29 06:00:35 1999
From: narasimha.ayyagari at mciworld.com (narasimha.ayyagari)
Date: Mon Jun  7 17:17:56 2004
Subject: unsubscribe
Message-ID: <002701bf3a2e$63109140$901c143f@narasimha>

unsubscribe



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



From gtn at ebt.com  Mon Nov 29 06:09:12 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:56 2004
Subject: A call for reason
In-Reply-To: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
Message-ID: <001401bf3a2f$afac45c0$0100007f@ebt.com>

If you have a look at my posting of 11/15/99

  http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0500.html

you'll see that I basically agree with your logic. The point is that
you don't really need to define a new syntax, but rather define the
application conventions for using an existing syntax (ideally using
a sophisticated schema mechanism as you suggest).

Another way of looking at it would be to look at a stream of SAX
events as tokens of a language. You want to constrain the grammar
(the way the tokens can be organized), not the way the tokens
are formed.

> The XML 1.0 spec allows an application to accept and reject 
> any subset of XML; it only makes demands of the XML processor 
> that the application contains.  I believe this is in full 
> conformance with the spirit of XML as well, as it's only the 
> parsing technology that it strives to make universal.
> 
> Yet if the application is going to reject that comment or 
> that PI or that non-English element type name in the end, 
> what difference does it make to the outside world whether it 
> is the parser layer that makes the decision?  Each 
> application in a ring of applications exchanging XML is 
> already beholden to conform to a particular schema or set of 
> schemas, so it's already the business of this ring to decide 
> what constitutes acceptable XML.
> 
> Provided that the SML effort yields a subset of XML, as it 
> should, SML should end up being a label for a group of 
> document types -- nothing more.  One may then label an 
> application as SML-compliant.  Rings of SML-compliant 
> applications may surface, but for most uses such rings will 
> be further constrained to a finite set of document types.  If 
> we had a schema language of sufficient richness -- expressing 
> name production rules and general syntactic layout -- we 
> could even use it to express the SML class of document types.
> 
> What's wrong with defining classes of XML document types and 
> restricting applications to using XML belonging to these 
> classes?  The notion sounds useful for much more than 
> identifying the set of 'simple' document types.  Is this not 
> reasonable?


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



From gtn at ebt.com  Mon Nov 29 06:24:43 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <199911290529.VAA03669@hawk.prod.itd.earthlink.net>
Message-ID: <001501bf3a31$da6e1840$0100007f@ebt.com>

> >The XML that is most important is the XML that can't be seen...
> 
> We are finding that just the opposite is true.  Both the 
> technical and the business savvy are designing DTDs, and both 
> the technical and the business savvy fully expect to be able 
> to see the XML.

The techies I can understand, the business folk, I find hard to
believe... and if it is the case in your business, I'll bet it's 
a temporary phenomena.

I've dealt with the business folk for a number of years (too many
to comfortably remember!), first as an SGML evangelist, then an 
XML evangelist, and in all kinds of technical and consulting roles. 
In general, the folk I've dealt with love the ROI of XML (when
implemented well), but couldn't care less about it's syntax. They
understand the *idea* of a DTD (or information architecture), 
can sometimes *help* in designing one, but wouldn't be caught 
dead writing one themselves, and probably couldn't if they tried.

This is perfectly natural when you think about it. How many people
do you know who actively create, and consistently use word 
templates? Probably not many. Many more create Execel spreadsheet 
templates, and databases... but how many people there use VB or 
SQL? 

Humans tend to relate technology to the world as they see it. I
know a number of business folk that have secretaries read their email,
because that is the way they relate to the technology.... you
may be talking to a different mix though... maybe CIO, or perhaps 
CTO level folk... but even there, I'd say the infactuation with
XML syntax will soon disappear.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 07:02:53 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:56 2004
Subject: A call for reason
In-Reply-To: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
Message-ID: <000001bf3a38$18e7fea0$099918d1@docuverse1>

>I'm learning through the grapevine that some people of 
>influence are opposed to the SML effort.

As the person who started the SML effort, I have this to
say to them:

If you have concerns, please voice them and suggest ways
to minimize your concerns.  Let us work together to
prevent unnecessary conflicts.

Just remember that not all things are controllable and
not all people can be influenced.  Killing all the
butterflies in Peking will not rid Kansas of tornadoes.
Let the butterfly be and hope it drops dead on its own
in the winter.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 09:09:03 1999
From: oren at capella.co.il (Oren Ben-Kiki)
Date: Mon Jun  7 17:17:56 2004
Subject: Fw: [SML] Whether to support Attribute or not?
Message-ID: <0c6c01bf3a47$a90fb090$4602a8c0@capella.co.il>

On Sat, 27 Nov 1999, Paul Tchistopolskii wrote:
> S-XSLT should be written anyway. XT will hardly fit into
> cell phone ;-)
>
> S-XSLT processor should be much easier to write than
> it was to write XT ( the same is with SML parser, S-SAX, e t.c.):

Question: how far does this go? If we have SSLT, would we also have SLink,
SSchema, SPath (well, obviously we'll have that; no matching on attributes),
...? How about SHTML?

Admittedly it is fun having the X-people do some work, then come along a
year or two later, with perfect hindsight, to create a better spec. Besides,
the deserve it, since they have done the same to SGML :-)

Is this a way to resolve the problem of trying to build specs in Internet
time - "must get it out the door, we'll re-think it in the next generation"?
I have mixed feelings about this...

Clark C. Evans <clark.evans@manhattanproject.com> wrote:
> I'm all for this; the SSLT definition should be
> stream-only; in otherwords, it should not require
> random access to the entire SML stream.

SSLT would have simplified XPath syntax, since there is no issue of
attributes. If SSLT is to be written in SML, the XSLT syntax would have to
be reworked, but this is pretty mechanical - in fact it could be done
automatically both ways (using an XSLT stylesheet :-). So far, this doesn't
gain much. An XSLT processor is complicated enough that it doesn't have much
to gain from SML.

Making SSLT streaming-only on the other hand, is an interesting notion. I
was always uncomfortable with XSLT's choice of requiring random access to
the input. There are many transformation jobs where the input is much larger
then the output - orders of magnitude larger.

S(treaming)SLT would be different from XSLT in the following ways:

- A template would be completely responsible for all the sub-tree below the
element it matches;
- A template would be limited to specifying a single pass on this sub-tree
(i.e., a single call to apply-templates, for-each, etc.).
- Therefore, side effects (variable assignment) would be allowed.

Sorting and numbering always require another "pass". We can either:

- Keep the XSLT model, which requires a buffer large enough to hold all the
sorted input tree fragments.
- Change the model so that sorting would be done on output tree fragments.
This reduces the language power in some ways.
- Disallow sorting altogether.

The second option is based, again, on the assumption that the result tree is
smaller then the input tree. Its consequences are:

- Templates are _always_ called in document order, even in sorted
invocations (important due to side effects).
- The computation of 'position' operation in sorted invocations would be
delayed until the sorting pass.

Doing a delayed 'position' computation would complicate the SSLT processor,
unless the use of this function is restricted to being embedded inside the
output tree. In particular, it would be illegal to use it in a condition or
in side effects. This way the SSLT processor could simply do the embedding
as part of the sorting pass.

Have fun,

    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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From iand at fdc.co.uk  Mon Nov 29 09:10:47 1999
From: iand at fdc.co.uk (Ian Davis)
Date: Mon Jun  7 17:17:56 2004
Subject: RSS and WAP - another RSS question
In-Reply-To: <3.0.6.32.19991128162111.00a0e290@gpo.iol.ie>
References: <3.0.6.32.19991128162111.00a0e290@gpo.iol.ie>
Message-ID: <4383.991129@fdc.co.uk>

On Sunday, November 28, 1999, 4:21:11 PM, Sean wrote:

> Yes, I've seen the description field but the data I have seen
> populating description fields has really fitted into the concept
> of an abstract. I don't want to abuse the <description> element
> by using it for something it was not intended for.

You might want to take a look at OCS [1], which is way of describing
directories of channels,  i.e. metadata for channels. Each channel
entry contains a description of the channel, categorisation and
contact details. Each channel can have multiple formats (RSS,
ScriptingNews, Avantgo, plain text, etc) each with their own
publishing schedules.

It's used currently by a number of channel providers and readers such
as XMLTree [2], Carmen's Headline Viewer [3] and StartsHere [4].

It should be easy enough to parse OCS for a WAP phone (in fact I
already do it indirectly at StartsHere [5])


I'm working on the next version (0.5) which will tidy up some of the
syntax. I'm also soliciting for any additional features people have for
the format - just mail them to me and I'll see how they fit.

Ian

-- 
Internet Alchemy - http://InternetAlchemy.org/

[1] http://InternetAlchemy.org/ocs/
[2] http://www.xmltree.com/export/ocs.cfm
[3] http://www.vertexdev.com/HeadlineViewer
[4] http://theweb.startshere.net/channels.phtml?format=OCS
[5] http://theweb.startshere.net/channels.phtml?format=WML




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 09:41:03 1999
From: francis at redrice.com (Francis Norton)
Date: Mon Jun  7 17:17:56 2004
Subject: A call for reason
References: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
Message-ID: <3842496E.5347E04F@redrice.com>

Joe Lapp wrote:
> 
...
Likewise, no finite set of DTDs can define the set of documents whose
element type names are all letters or the set of documents whose
elements don't use attributes.  
...

I haven't really been following the SML threads, but it cocurs to me
that "the set of documents whose elements don't use attributes" could
certainly be defined in Rick Jellife's Schematron using impeccably pure
XPATH technology and semantics.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From larsga at garshol.priv.no  Mon Nov 29 09:45:49 1999
From: larsga at garshol.priv.no (Lars Marius Garshol)
Date: Mon Jun  7 17:17:56 2004
Subject: [SML] RE: Forget SML. We need RTSML.
In-Reply-To: <199911290009.QAA24435@avocet.prod.itd.earthlink.net>
References: <199911290009.QAA24435@avocet.prod.itd.earthlink.net>
Message-ID: <m3iu2lwrzl.fsf@ifi.uio.no>


* Joe Lapp
|
| I don't understand this proposal.  You can't represent structured
| data with it.  What am I missing?

A functioning irony detector?

--Lars M.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 09:57:25 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:57 2004
Subject: Fw: [SML] Whether to support Attribute or not?
In-Reply-To: <0c6c01bf3a47$a90fb090$4602a8c0@capella.co.il>
Message-ID: <Pine.GSU.4.10.9911290137530.9457-100000@netcom9.netcom.com>

On Mon, 29 Nov 1999, Oren Ben-Kiki wrote:

> SSLT would have simplified XPath syntax, since there is no issue of
> attributes. If SSLT is to be written in SML, the XSLT syntax would have to
> be reworked, but this is pretty mechanical - in fact it could be done
> automatically both ways (using an XSLT stylesheet :-). So far, this doesn't
> gain much. An XSLT processor is complicated enough that it doesn't have much
> to gain from SML.
> 
> Making SSLT streaming-only on the other hand, is an interesting notion. I
> was always uncomfortable with XSLT's choice of requiring random access to
> the input. There are many transformation jobs where the input is much larger
> then the output - orders of magnitude larger.

Definitely.  Let's talk not just about XSLT translation, but about
querying in general (which is likely to be based on XPATH syntax and the
same sort of data model as XSLT).  For example, the TEI crowd is probably
going to want the ability to extract fragments from large corpora of text
marked up potentially at the syllable level.  That's not going to be
practical if you're restricted to a data model that requires building a
tree for the entire source document.

I would say that developing a data model to support streaming
query/extraction for XML is a far more worthwhile endeavor than developing
a stripped-down data syntax whose main purpose is to allow script kiddies
(not to be confused with Desperate Perl Hackers) to repeatedly cargo-cult
parsers so that their bosses don't get freaked out by the presence of NIH
code, some of which might be (gasp!) Open Source.

> 
> S(treaming)SLT would be different from XSLT in the following ways:
> 
> - A template would be completely responsible for all the sub-tree below the
> element it matches;
> - A template would be limited to specifying a single pass on this sub-tree
> (i.e., a single call to apply-templates, for-each, etc.).
> - Therefore, side effects (variable assignment) would be allowed.

As I see it, you'd need a way of giving names to path expressions and
their result sets, and a way of making one path expression conditional on
the success of another.  Thus a path expression that goes down the
conceptual tree along the child:: axis, then back up the tree along
Ancestor::, and then sideways along following-sibling could be replaced
with three child::-only path expressions that would have to match in
sequence (though not the same order as they would appear in the full XPath
expression), each of which would "squirrel away" the conceptual nodes that
matched.  The idea is to limit the "running storage" required to a stack
of element names encountered along the current branch of the conceptual
tree and the text content of the current element (along with any
squirreled-away data).

An interesting question is whether a full XPath expression could be
automatically decomposed into a sequence of "sequential-path" expressions.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 10:19:25 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:57 2004
Subject: A call for reason
In-Reply-To: <001401bf3a2f$afac45c0$0100007f@ebt.com>
References: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
Message-ID: <3.0.6.32.19991129095816.009bb980@gpo.iol.ie>

[Gavin Nichol]
>If you have a look at my posting of 11/15/99
>
>  http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/0500.html
>
>you'll see that I basically agree with your logic. The point is that
>you don't really need to define a new syntax, but rather define the
>application conventions for using an existing syntax (ideally using
>a sophisticated schema mechanism as you suggest).
>
>Another way of looking at it would be to look at a stream of SAX
>events as tokens of a language. You want to constrain the grammar
>(the way the tokens can be organized), not the way the tokens
>are formed.
>
This is the tack I took in Pyxie. Pyxie is 
an open source XML processing library for
Python that is entirely based on a simple post-SAX notation
I call "PYX". PYX is essentially a stripped down ESIS.
The library is Open Source and will be available
at http://www.pyxiw.org after XML'99.

regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 10:22:54 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:17:57 2004
Subject: A call for reason
In-Reply-To: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
References: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
Message-ID: <19991129052249.K27642@w3.org>

On Mon, Nov 29, 1999 at 12:03:11AM -0500, Joe Lapp wrote:
> I'm learning through the grapevine that some people of influence are opposed to the SML effort.  I'm going to argue that provided SML ends up a subset of XML, as it should, the only conflict SML has with XML is the name.  I walk through this step-by-step out of fear that I might leave someone with insufficient information to read between the lines.

  My personal opinion is that SML is not a problem. I do understand that
some people may not like some of the extra feature inherited from SGML
(for example DTD syntax and validation limit, PIs), and using only a subset of
XML makes sense in a lot of cases. Defining formally a sub level of support
would help sharing a common software base, so it's sound to me.

  But I start to be quite worried at the idea that for whatever reason
SML documents may turn not being a well formed XML one, c.f.:

  http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/1143.html

Because it's clear that SML data have to be exported widely and reused easily,
that's the goal of the whole XML effort and it's reason for success.
If suddently XML "like" data starts to appear in mass, but breaking
the XML parser, my fear is that (like we have seen for HTML) parser will
loosen their checkings and we will inherit again an HTML like mess ! And
that I will fight with all the energy I can.

  Like Tim Bray expressed a couple of time, I'm not sure that the few extra
feature of Well Formed XML will really make huge differences in the cost
of implementations, but trying it definitely makes sense and it's hard for
a single person to really appreciate all the specrum of uses in which 
XML is being applied right now.

  So SML is an interesting idea, but KEEP it Well Formed XML !

Daniel (speaking for himself obviously !)

-- 
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 11:04:21 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:17:57 2004
Subject: [SML] RE: Forget SML. We need RTSML.
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90BE@sohos002.ied-support.net>

Joe Lapp wrote:
> I don't understand this proposal.  You can't represent 
> structured data with
> it.  What am I missing?

Good point. What we need is some way of nesting RSTML documents inside
each other. Now that RSTML has been operating for over a day with good
feedback from users (no-one has said they don't understand it) I think
it's time to enhance the feature-set. I propose that we allow an RSTML
document to contain other RSTML documents:

	document ::= StartTag (Stuff | document) EndTag
 	StartTag ::= '<RTSML>'
 	EndTag   ::= '</RTSML>'

One other thing; I'm organising a conference on RSTML. There won't
actually be any sessions or even an event, since the idea is that if
anyone actually wants to attend the conference then RSTML is obviously
too complicated to understand in 3 minutes (recall from 1.0 that "RSTML
'MUST' be understood in less time than it takes to boil an egg"). If
even one ticket is sold RSTML would need to be revised, and so the
conference would have to be cancelled. The conference won't be on
December 12th. Everyone OK with that date?

Best regards,

Mark

Author - Building E-commerce and Satellite Control Systems with RSTML
(Next year)

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



From jamesr at steptwo.com.au  Mon Nov 29 11:13:27 1999
From: jamesr at steptwo.com.au (James Robertson)
Date: Mon Jun  7 17:17:57 2004
Subject: A call for reason
In-Reply-To: <199911290459.UAA15386@hawk.prod.itd.earthlink.net>
Message-ID: <4.2.0.58.19991129220752.00d08b80@203.41.126.17>

At 16:03 29/11/1999 , Joe Lapp wrote:

>I'm learning through the grapevine that some people of influence are 
>opposed to the SML effort.

And there's some others of us who are
_obviously_ opposed to SML.

Who needs a grapevine?

(Gee, this is all wasting a lot of
bandwidth.)

J


-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
Illumination: an out-of-the-box Intranet solution

http://www.steptwo.com.au/
jamesr@steptwo.com.au

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



From Dimitris.Dimitriadis at linq.com  Mon Nov 29 11:29:11 1999
From: Dimitris.Dimitriadis at linq.com (Dimitris Dimitriadis)
Date: Mon Jun  7 17:17:57 2004
Subject: A call for reason
Message-ID: <65C559669D59D211B5320008C7B987395C5A42@ORION>

Does anyone else except for me think of the new language advocated in
Orwell's 1984? If so, that's simply double-plus-good.

D. Dimitriadis

-----Original Message-----
From: James Robertson [mailto:jamesr@steptwo.com.au]
Sent: Monday, November 29, 1999 12:09 PM
To: xml-dev@ic.ac.uk
Subject: Re: A call for reason


At 16:03 29/11/1999 , Joe Lapp wrote:

>I'm learning through the grapevine that some people of influence are 
>opposed to the SML effort.

And there's some others of us who are
_obviously_ opposed to SML.

Who needs a grapevine?

(Gee, this is all wasting a lot of
bandwidth.)

J


-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
Illumination: an out-of-the-box Intranet solution

http://www.steptwo.com.au/
jamesr@steptwo.com.au

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 11:42:34 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:17:57 2004
Subject: [SML] Data Markup Language?
In-Reply-To: <199911290105.RAA22163@avocet.prod.itd.earthlink.net>
Message-ID: <003101bf3a5e$b3414800$ab20268a@pc-lrd.bath.ac.uk>

> If we decide that SML is for data and not for publishing, should we then
> rename SML to Data Markup Language (DML)?

Data vs Publishing? How do you define the boundaries there? We're commonly
taking SGML/XML markup of 'publishing' data (abstracts, titles, authors,
etc)
and using this data as XML messages ('data') between systems. So we
seem to be lying on the boundaries here.

> The real answer to this question depends on the audience that is
interested in
> SML, I think.  So it would probably be sufficient to refute my suggestion
by
> having a large enough group of people express interest in SML for
publishing.

What is SML about anyway? What are the benefits beyond reductionism?
Hard to be interested when you don't know what its for.

Personally I'm waiting to see what APIs might be layered on top of
SML, and then possibly retrofit them to an XML parser and then be on my
way...

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 13:28:03 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:57 2004
Subject: [SML] Data Markup Language?
In-Reply-To: <003101bf3a5e$b3414800$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <000001bf3a6d$db76b760$099918d1@docuverse1>

I agree that there is a rather vague boundary between
data and publishing.

>What is SML about anyway? What are the benefits beyond
>reductionism?  Hard to be interested when you don't
>know what its for.

The problem is that people who are interested in SML
are approaching with a rather wide varietry of needs.
My own reason for suggesting SML was finding a right
balance between two primary definitions of the word
'simple': minimal and easy.

Benefit wise, I believe the EBNF v0.2 is minimal
enough to provide most, if not all, of the benefits
XML offers at 100% increase in speed and 50% reduction
in code size.  I also believe it is also simple enough
to implement in hardware to be incorporated into small
devices (SML Ring?).  This is just a guess so don't
bother saying 'prove it or else'.

>Personally I'm waiting to see what APIs might be layered
>on top of SML, and then possibly retrofit them to an
>XML parser and then be on my way...

SML's impact on DOM API should be fairly significant.
At least half of the interface and methods can be
thrown out in SDOM.  Effect on SAX should be somewhat
less though.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From obecker at informatik.hu-berlin.de  Mon Nov 29 13:27:35 1999
From: obecker at informatik.hu-berlin.de (Oliver Becker)
Date: Mon Jun  7 17:17:57 2004
Subject: RSS and WAP - another RSS question
Message-ID: <199911291327.OAA06351@mail.informatik.hu-berlin.de>

Hi,

may someone give me a hint what RSS is an abreviation for.
- Royal Statistical Society?
- Ribbed Smoked Sheets?
- Remote Sensing Society?
- Rashtriya Swayamsevak Sangh?
- Radio Science Subsystem?
- Reusable Space System?
(Results from HotBot)
I like these acronyms! ;-)

Well - it must have something to do with channels and Netscape ...
Weblinks for further reading welcome.

Regards,
Oliver


/-------------------------------------------------------------------\
|  ob|do        Dipl.Inf. Oliver Becker                             |
|  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
|  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
\-------------------------------------------------------------------/


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 13:40:06 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:17:57 2004
Subject: A call for reason
In-Reply-To: <19991129052249.K27642@w3.org>
Message-ID: <000301bf3a6f$96de5fc0$099918d1@docuverse1>

>But I start to be quite worried at the idea that for whatever reason
>SML documents may turn not being a well formed XML one, c.f.:
>  
>http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/1143.html

The message Daniel quoted was mine asking opinions on the
idea of removing the name production rule from WF constraints.

My intent was that there is no real need to make sure that all
the characters in the tag name are valid characters especially
since the valid character set is rather beastly.

Rick Jeliffe who was largely responsible for that valid name
character set wanted to remove the invalid name error reporting
requirement but was apparently voted down by XML WG.  I am
just proposing that same idea again.  If SML processors are
not required to report the error, then there is no need to
check each character anymore which will speed things up and
take up less space.

Net result is that SML data will be well-formed but invalid
name error will not be reported.  Is this too much to ask?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Dimitris.Dimitriadis at linq.com  Mon Nov 29 14:18:18 1999
From: Dimitris.Dimitriadis at linq.com (Dimitris Dimitriadis)
Date: Mon Jun  7 17:17:57 2004
Subject: A call for reason, --somewhat refined--
Message-ID: <65C559669D59D211B5320008C7B987395C5A49@ORION>

I should say, initially, that I share the ambition of SML, provided that
this means a simpler, no-extras, substantial and somewhat complete XML.
However, without being an XML-guru, I should point out two or three things I
think one should take into account when deciding between XML and SML.

1. No language is complete. Not even natural languages can be used to model
complex information structures. This seems to point toward empbracing SML,
since we, or so it seems, do not need the added complexity on offer by XML
(or, rather, we could come away with a simpler version of XML, namely SML).
Given that not even XML can be used to full effect, why bother with all the
extras?

2. However, without the use of attributes (one of the things that, if I
understand correctly, would disappear in SML), it seems we would miss out on
many of the features that make XML cross-referential. This is an essential
feature of modeling languages. We could of course use elements within
elements to express some advanced features, but it seems attributes and some
meta-understanding gives us a simpler tool to achieve the same thing.
Provided that we would need large and comples structures in SML to express
things we could express in a more simple fashion in XML, I can't really see
the point in changing standards.

To my understanding, SML would be well-suited for writing fairly simple
structures. Of course it is. The question, however, is if we should stick to
simplicity just because we haven't really started understanding how complex
XML can really be, just because we, at present, use XML for fairly simple
tasks. That sounds quite conservative. 

I look forward to continuing this debate. 

Kind regards

D. Dimitriadis



-----Original Message-----
From: James Robertson [mailto:jamesr@steptwo.com.au]
Sent: Monday, November 29, 1999 12:09 PM
To: xml-dev@ic.ac.uk
Subject: Re: A call for reason


At 16:03 29/11/1999 , Joe Lapp wrote:

>I'm learning through the grapevine that some people of influence are 
>opposed to the SML effort.

And there's some others of us who are
_obviously_ opposed to SML.

Who needs a grapevine?

(Gee, this is all wasting a lot of
bandwidth.)

J


-------------------------
James Robertson
Step Two Designs Pty Ltd
SGML, XML & HTML Consultancy
Illumination: an out-of-the-box Intranet solution

http://www.steptwo.com.au/
jamesr@steptwo.com.au

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



From zvia at netmanage.co.il  Mon Nov 29 15:00:36 1999
From: zvia at netmanage.co.il (Zvi Avraham)
Date: Mon Jun  7 17:17:57 2004
Subject: RSS and WAP - another RSS question
References: <199911291327.OAA06351@mail.informatik.hu-berlin.de>
Message-ID: <384294FC.BFF25C01@netmanage.co.il>

Rich Site Summary

Oliver Becker wrote:

> Hi,
>
> may someone give me a hint what RSS is an abreviation for.
> - Royal Statistical Society?
> - Ribbed Smoked Sheets?
> - Remote Sensing Society?
> - Rashtriya Swayamsevak Sangh?
> - Radio Science Subsystem?
> - Reusable Space System?
> (Results from HotBot)
> I like these acronyms! ;-)
>
> Well - it must have something to do with channels and Netscape ...
> Weblinks for further reading welcome.
>
> Regards,
> Oliver
>
> /-------------------------------------------------------------------\
> |  ob|do        Dipl.Inf. Oliver Becker                             |
> |  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
> |  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
> \-------------------------------------------------------------------/
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 15:27:01 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:17:57 2004
Subject: RSS and WAP - another RSS question
In-Reply-To: <199911291327.OAA06351@mail.informatik.hu-berlin.de>
Message-ID: <Pine.GSU.4.10.9911290720120.23681-100000@netcom9.netcom.com>



On Mon, 29 Nov 1999, Oliver Becker wrote:

> may someone give me a hint what RSS is an abreviation for.

It originally stood for RDF (Resource Description Framework, a W3C
Recommendation) Site Summary, but its developers changed the syntax (as of
version 0.91, the current version) to something that wasn't RDF, so they
renamed it Rich Site Summary.


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



From jrgardn at emory.edu  Mon Nov 29 15:42:43 1999
From: jrgardn at emory.edu (John Robert Gardner)
Date: Mon Jun  7 17:17:57 2004
Subject: Architectural Forms and Oracle (or SIM) [was Re: "Multiple" Namespaces?
 (but NOT for HTML)]
In-Reply-To: <3822FEFD.B399D565@prescod.net>
Message-ID: <Pine.GSO.4.05.9911291023250.16352-100000@jet.cc.emory.edu>

Rather than strictly re-visit the multiple namespaces issue (or detract
from the SML/RTSML/XML/WAP/RSS etc. threads), I wanted to request if list
members can allow me to inquire further regarding a possible solution
ssuggested by Paul as to my question some time back, viz. the following
(question follows this short snip-set of preceding discussion):

On Fri, 5 Nov 1999, Paul Prescod wrote:

> John Robert Gardner wrote:
> > 
> > <GoalScenario>
> > Heinrich at Humboldt U. in Berlin is dilligently searching the world's
> > various library resources with his Dublin-Core-Based engine for
> > <Creator>Tillich</Creator> and we want his DC system to transparently find
> > the wealth of Tillich articles we'd have online.
> > </GoalScenario>

> Yes, architectural forms work fine with XML now. But to some degree you
> must choose your solution based on the software available. There are
> various toolkits that are archform aware but I don't know of any
> A mythical architectural form-smart search engine would "pretend" to do
> that conversion, in real-time, when the query was done and cache the
> results intelligently. But such a thing doesn't exist as a general tool.
> 
> If is is structured property name-value pairs then you need something
> object orientish like an RDF engine or an object database. You need name
> aliasing but it needs to be hierarchical.
> 
> If the proper model is elements within elements then you need an
> XML-specific solution like architectural forms. That's going to be
> harder to find.

Paul's suggestion of Arch. forms is making more and more sense,
but--accordingly--it's getting me toward a little on the worrisome side as
to supporting software.  I've yet to begin puttering with PL/SQL for our
current Oracle setup and, while we're preparing soon to seriously look at
SIM, I'm wondering if anyone out there has suggestions of possible
software we could/should be looking at (Steve Muench on this?) for working
with ORacle and Arch. Forms for the time being?

I've looked at Eliot Kimber's article ofn SGML Architectures at
http://www.isogen.com/papers/archintro.html and noted Clark's SP works
with Arch Forms, beyond htis, however, I'm uncertain as to where to
proceed/turn.

Suggestions?

Thank you very much,

jr


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



From rev-bob at gotc.com  Mon Nov 29 15:47:05 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:17:57 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <199911291046901.SM01048@Unknown.>

> >   Consider:   
> >     
> >     <element att="val"> <content/> </element>
> 
> How about this?
> 
> 	<element <att>val</att>> <content/> </element>
> 
> This is for sure not XML/SGML, but it generalizes the recursive
> pattern.  If you want an attribute on the attribute, you write:
> 
> 	<element <att <att-of-att>subvalue</att-of-att>>val</att>>  ...

This might be the right time to note that the iHTML server-side scripting package 
operates in exactly that manner.  An actual scrap of code (from my site) looks like:

<iSET sbit=`<iRANDOM dbname="gotc" table="SQLcode">`>

The main bugaboo in using this structure, at least where iHTML is concerned, concerns 
quotes.  The above works fine, because the back-sq's (a) properly contain the unparsed 
iRANDOM tag and (b) do not appear in the data which replaces that tag.  However, this 
can get really nasty if you're not careful; it helps if you actually break down the recursion 
into successive statements.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webMethods.com  Mon Nov 29 15:52:13 1999
From: jlapp at webMethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:58 2004
Subject: [SML] Namespace support
Message-ID: <3.0.32.19991129105311.01493a40@nexus.webmethods.com>

One drawback to excluding attributes is that we lose the ability to declare
XML namespaces.  Since I know many people with gripes about the complexity
of XML namespaces, we might also take the opportunity to simplify there.

In particular, I want to be able to leverage all the code that has been
implemented for XML namespaces; we don't want to reinvent the wheel, and we
need to be fully compatible with XML.

Maybe we should support xmlns attributes on the root element only.  When
you have to mix elements from different namespaces, you may have to change
the attributes of the root element to reflect all the namespaces.  This may
involve resolving namespace prefix collisions, but this is fine with me (we
already find the need to do this on occasion in full XML).

I don't see any way around supporting namespaces in SML.
--
Joe Lapp                     (Looking for some good people to
Senior Engineer               help create XML technologies that
http://www.webMethods.com     connect businesses to businesses
jlapp@webMethods.com          over the web.)

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



From nisse at lysator.liu.se  Mon Nov 29 16:06:37 1999
From: nisse at lysator.liu.se (Niels Möller)
Date: Mon Jun  7 17:17:58 2004
Subject: About sml and internationalization
In-Reply-To: Sean McGrath's message of "Sun, 28 Nov 1999 10:35:45 +0000"
References: <NBBBJPGDLPIHJGEHAKBAGEMOEHAA.martind@netfolder.com> <3.0.6.32.19991128103545.00a0ab80@gpo.iol.ie>
Message-ID: <nnhfi5e0zp.fsf@sanna.lysator.liu.se>

Sean McGrath <digitome@iol.ie> writes:

> I am thinking about the issue to with allowing/disallowing
> sets of Unicode characters in element type names as per XML
> 1.0.
> 
> If SML has very few special tokens
> e.g. "<", "&" and whitespace, what would happen
> if any character outside this teeny weeny set is
> allowed in an element type name.

I would say this is the way to go. And I have seen it done before,
both with eight-bit charsets like latin1 andwith unicode.

It gives people the ability to shoot themselves in the foot by using
strange characters (my favourite is using non-breakable space in
variable names in emacs lisp). But I still think it is the way to go:
The parser and language can define a small set of characters as
special, and just pass on whatever is between those special characters
to the application.

If you think about it this way, most of the charset considerations can
be removed from the parser. Treat the input as a sequence of
non-negative integers (which may be 7, 8 or 36 bits wide, depending on
the application; if you think in C++, the parser could be a template
parameterized on the character type). If an application needs to
handle several charsets, it can use something like a content-type:
text/sml; charset = iso-8859-2 header to convert the input into
unicode before feeding it into the parser.

One could define the special characters more abstractly, and leave it
to the application to tell the parser how an "<" is represented today,
but I think that's overabstracting things. Using plain ascii values
(possibly embedded into an ascii superset like unicode or latin-2)
should be good enough.

This line of thinking also means that "whitespace", as far as the
parser is concerned, should be limited to a few ascii characters. SPC
and NL ought to be enough. To keep with tradition, perhaps TAB an CR
as well. Having the parser recognize all unicode whitespace characters
as adds some complexity. (There are 5 spacing control characters in
traditional ASCII, and ordinary space, non-breakable space (in latin-x
and unicode), and an additinal 18 in the rest of unicode. I.e 25 in
all).

/Niels

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 16:03:00 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:17:58 2004
Subject: How to keep  "useless" information with SAX (2?).
In-Reply-To: Paul Tchistopolskii's message of "Mon, 22 Nov 1999 22:10:52 -0800"
References: <026e01bf3579$7f8e2440$5df5c13f@PaulTchistopolskii>
Message-ID: <m3puwtjnio.fsf@localhost.localdomain>

Paul Tchistopolskii <paul@qub.com> writes:

> With Sun's extensions to SAX API I could get 
> the content of <!DOCTYPE and the content of comment.
> 
> Unfortunately, whitespace ( including the 
> newline) between those constructions has been 
> lost.

Correct -- SAX was not designed for this type of application.  Think
of SAX as an interface that reports the logical rather than the
physical structure of a document.  Of course, SAX can be extended to
provide extra information, and the long-stalled SAX2 (mea culpa) was
designed to give a framework for doing just that.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From njoshi at dswebnet.com  Mon Nov 29 16:16:10 1999
From: njoshi at dswebnet.com (Rashmi Joshi)
Date: Mon Jun  7 17:17:58 2004
Subject: unsubscribe
Message-ID: <006901bf3a84$ee812b80$3caebdcf@njoshi.lebanon>

Unsubscribe


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



From njoshi at dswebnet.com  Mon Nov 29 16:19:30 1999
From: njoshi at dswebnet.com (Rashmi Joshi)
Date: Mon Jun  7 17:17:58 2004
Subject: UNSUBSCRIBE
Message-ID: <00d301bf3a85$6ab6f5e0$3caebdcf@njoshi.lebanon>

UNSUBSCRIBE


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 16:49:26 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:17:58 2004
Subject: Schema support in parsers?
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F278175@MDYNYCMSX1>

>Is anyone aware of any parsers which support the latest Schema 
>draft?

With the Xerces parser that IBM donated to apache.org you can write a
parsing program that supports both XML 1.0 DTDs and much of the September
W3C Schema proposal.

>Failing that, how about a tool(s) to go from a Schema to a DTD?
>(accepting that some schema constructs can be expressed in 
>a DTD).

Extensibility's XML-Authority can, although I'm not sure which draft and how
much of the Schema proposal it supports. 

Forgive my qualifications, but I'm sure it will get better quickly when the
proposal achieves Recommendation status.

Bob DuCharme       www.snee.com/bob       <bob@  
snee.com>  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Patrice.Bonhomme at loria.fr  Mon Nov 29 17:36:23 1999
From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme)
Date: Mon Jun  7 17:17:58 2004
Subject: XML Database: position papers ?
Message-ID: <199911291735.SAA02223@chimay.loria.fr>


Hi,

I am looking for some position papers that are doing a comparison of both 
relational model and object oriented approaches for XML database conception.

Thanks for any pointers,
Pat.

-- 
  ==============================================================
   bonhomme@loria.fr      Tel : 03 83 59 30 52 / 06 11 34 03 85
   http://www.loria.fr/~bonhomme                 Office : B.228
  --------------------------------------------------------------
   * Serveur Silfide  : http://www.loria.fr/projets/Silfide
  ==============================================================



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



From xml at searchtools.com  Mon Nov 29 17:45:40 1999
From: xml at searchtools.com (Avi Rappoport)
Date: Mon Jun  7 17:17:58 2004
Subject: DTD.com - new repository
In-Reply-To: <nnhfi5e0zp.fsf@sanna.lysator.liu.se>
References: <NBBBJPGDLPIHJGEHAKBAGEMOEHAA.martind@netfolder.com>
 <3.0.6.32.19991128103545.00a0ab80@gpo.iol.ie>
 <nnhfi5e0zp.fsf@sanna.lysator.liu.se>
Message-ID: <v04220804b4686a02970f@[171.66.196.146]>

 From the Gilbane Report:


LUMERIA ANNOUNCES DTD.COM
11/22/99

Lumeria, an infomediary incubator, announced the launch of DTD.com, a site
for web software developers that combines a web repository for XML DTDs with
a web-based tool for editing and creating DTDs. DTD.com offers web
developers two free benefits. First, DTD.com provides the XML community with
a free knowledge repository -- called the DTDwarehouse -- for storing and
sharing DTDs and information about each DTD. Secondly, DTD.com gives away a
free web-based knowledge management application, called the DTDfactory,
which lets XML developers mine the data in the DTDwarehouse, create their
own DTDs, validate them against industry standards, and share their
knowledge of DTDs with other developers. With the goal of becoming a
standard repository for all DTDs, DTD.com enables XML developers to upload
their own DTDs -- whether entire DTDs or suggested tags -- to the
DTDwarehouse to share with other developers. DTD.com will also aggregate
these DTDs or tags and submit them for approval by the appropriate standards
committees as a way of accelerating the standardization of XML. The
DTDwarehouse is stocked with over 180 DTDs covering a wide range of
subjects, from mathematics to science, government, education, and personal
profiling.

In addition, DTD.com supports Lumeria's proposed new standard for
personal profiling, called the Profile Markup Language (PML) -- an extremely
rich profile description and exchange platform, which is based on XML. PML
is an open source, industry-driven, XML-based collection of standards for
defining profile data. At the heart of PML is the PML DTD -- the set of
rules by which PML documents are created and interpreted. Lumeria created
PML in a drive to initiate an industry-wide movement to enable the flow of
profile information across platforms and applications, and thereby save both
consumers and businesses time and money. To encourage the widespread use of
XML, Lumeria gives away PML for free to all developers and sets up a
database of XML DTDs by subject. To encourage the use of PML, Lumeria has
made the protocol compatible not only with its own SuperProfile Identity
Management system but also with the upcoming Consumer Profile Exchange
(CPEX) protocol and data model. Lumeria is a member of the CPEX core working
group, which includes Oracle, IBM, Vignette, net.Genesis, Andromedia, and
the Sun-Netscape Alliance. www.lumeria.com


_______________________________________________________
Guide to Local Site, Intranet, and Portal Search Engines: 
<http://www.searchtools.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From lindsey at diac.com  Mon Nov 29 17:49:27 1999
From: lindsey at diac.com (William Lindsey)
Date: Mon Jun  7 17:17:58 2004
Subject: A call for reason
In-Reply-To: <000301bf3a6f$96de5fc0$099918d1@docuverse1>
Message-ID: <Pine.LNX.4.10.9911291036390.15199-100000@cobra.diac.com>

 (regarding name characters)

On Mon, 29 Nov 1999, Don Park wrote:

> Net result is that SML data will be well-formed but invalid
> name error will not be reported.  Is this too much to ask?

Yes, it is too much to ask.

Your SML data may be well-formed by some idea you have of
the meaning of the term, but the XML spec has a different, 
more precise definition of "well-formed".   A 
conforming XML processor is required to reject a
document with illegal element names. That document
is, therefore, not XML.

"Close" isn't good enough.

Cheers,
Bill


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 17:57:02 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:17:58 2004
Subject: A call for reason
In-Reply-To: <000301bf3a6f$96de5fc0$099918d1@docuverse1>
References: <19991129052249.K27642@w3.org> <000301bf3a6f$96de5fc0$099918d1@docuverse1>
Message-ID: <19991129125647.C28815@w3.org>

On Mon, Nov 29, 1999 at 05:42:27AM -0800, Don Park wrote:
> >But I start to be quite worried at the idea that for whatever reason
> >SML documents may turn not being a well formed XML one, c.f.:
> >  
> >http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/1143.html
> 
> The message Daniel quoted was mine asking opinions on the
> idea of removing the name production rule from WF constraints.
> 
> My intent was that there is no real need to make sure that all
> the characters in the tag name are valid characters especially
> since the valid character set is rather beastly.
> 
> Rick Jeliffe who was largely responsible for that valid name
> character set wanted to remove the invalid name error reporting
> requirement but was apparently voted down by XML WG.  I am
> just proposing that same idea again.  If SML processors are
> not required to report the error, then there is no need to
> check each character anymore which will speed things up and
> take up less space.
> 
> Net result is that SML data will be well-formed but invalid
> name error will not be reported.  Is this too much to ask?

  Well, HTML history proved it:
    if parsers don't check for conformance, users won't either.

XML parser don't have to check for validity, how many of the XML
based apps in deployment now do check for it ?

So is SML parsers don't check for valid characters, how will user
discover the problem, why will they care, how will XML parser user
will handle the problem?
The point is that i'm not optimistic about the answer,

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 18:06:26 1999
From: francis at redrice.com (Francis Norton)
Date: Mon Jun  7 17:17:58 2004
Subject: Still news
References: <002601bf39ff$f8ff2e20$788410d2@mmm.tigue.com>
Message-ID: <3842BFDE.133CCA70@redrice.com>

Pretty much the same thing looks like happening here in the UK, minus
some unpleasant baggage that threatened to derail the whole proposal. 

http://www.fipr.org/uk_ecomm_bill/qupr.html

Francis.

John Tigue wrote:
> 
> While we're talking news, I think the following will
> be very significant for XML:
> 
> http://news.cnet.com/news/0-1005-200-1454205.html
> 
> Senate approves slimmed-down digital signature bill
> 
> WASHINGTON--The Senate unanimously approved legislation
> to promote e-commerce by giving contracts signed in a
> digital format the same legal standing as the
> ink-and-paper kind.
> 
> -John
> 
> Tim Bray wrote:
> > XML is the cover story on PC week; coverage effusive
> > even by the standards we've started getting used to.
> > Check out http://www.zdnet.com/pcweek/
> >
> > -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Mon Nov 29 18:22:59 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:58 2004
Subject: [SML] Data Markup Language?
References: <003101bf3a5e$b3414800$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <00f601bf3a97$1af50080$0b00a8c0@grissom>

Leigh Dodds <ldodds@ingenta.com> wrote:

<< Data vs Publishing? How do you define the boundaries there?

Data interchange:
computer -> computer (or application -> application)

The consumer is another application.

Publishing:
computer -> person.

The consumer is a person. The XML is used to render a page for a person to
view.


----- Original Message -----
From: Leigh Dodds <ldodds@ingenta.com>
To: <xml-dev@ic.ac.uk>
Sent: Monday, November 29, 1999 3:41 AM
Subject: RE: [SML] Data Markup Language?


> > If we decide that SML is for data and not for publishing, should we then
> > rename SML to Data Markup Language (DML)?
>
> Data vs Publishing? How do you define the boundaries there? We're commonly
> taking SGML/XML markup of 'publishing' data (abstracts, titles, authors,
> etc)
> and using this data as XML messages ('data') between systems. So we
> seem to be lying on the boundaries here.
>
> > The real answer to this question depends on the audience that is
> interested in
> > SML, I think.  So it would probably be sufficient to refute my
suggestion
> by
> > having a large enough group of people express interest in SML for
> publishing.
>
> What is SML about anyway? What are the benefits beyond reductionism?
> Hard to be interested when you don't know what its for.
>
> Personally I'm waiting to see what APIs might be layered on top of
> SML, and then possibly retrofit them to an XML parser and then be on my
> way...
>
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From KenNorth at email.msn.com  Mon Nov 29 18:27:44 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:58 2004
Subject: [SML] Data Markup Language?
References: <003101bf3a5e$b3414800$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <00fe01bf3a97$bd9207c0$0b00a8c0@grissom>

Leigh Dodds <ldodds@ingenta.com> wrote:

<< Data vs Publishing? How do you define the boundaries there?

Data interchange:
computer -> computer (or application -> application)

The consumer is another application. Often used for business-to-business
(B2B) integration.

Publishing:
computer -> person.

The consumer is a person. The XML is used to render a page for a person to
view.

We surveyed this at three recent conferences and no one seemed confused
about the distinction.

<< We're commonly taking SGML/XML markup of 'publishing' data (abstracts,
titles, authors,
etc) and using this data as XML messages ('data') between systems.

A book distributor sending orders to a publishing house using XML for data
interchange (B2B integration, e-commerce messaging, etc.). A distributor
might send catalog updates in XML to a retailer (data interchange), and the
retailer renders new HTML pages for a Web site (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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ht at cogsci.ed.ac.uk  Mon Nov 29 18:30:30 1999
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:17:58 2004
Subject: XML Schema One-day intensive tutorial
Message-ID: <f5b66ylgngg.fsf@cogsci.ed.ac.uk>

It's not too late to sign up [1] for the tutorial I'm giving at Markup
'99/XML '99 on Sunday: a full day introduction to the up-to-the minute
state of XML Schema.  We'll be working from a pre-publication version
of the next public working draft, due out 16 December, currently
anticipated to be the last draft before the WG submits a version to
Last Call.  Don't miss this chance to pester one of the editors with
your personal opinions about what is and isn't right about this
important impending W3C recommendation.

Please may I?

ht

[1] https://www.signupcenter.com/gca/attendee/online.html
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

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



From gtn at ebt.com  Mon Nov 29 18:39:25 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:17:59 2004
Subject: [SML] Data Markup Language?
In-Reply-To: <000001bf3a6d$db76b760$099918d1@docuverse1>
Message-ID: <001301bf3a98$79d0cbb0$2b7370c6@ebt.com>

> SML's impact on DOM API should be fairly significant.
> At least half of the interface and methods can be
> thrown out in SDOM.  Effect on SAX should be somewhat
> less though.

I debate this. I could just as easily say that SDOM doesn't
expose entities, and is read-only, but is still layered on
top of XML 1.0. I've done something like this a few times
over the last year, and every one of those API's was much
simpler than the DOM.

The question is not one of syntax, but exposure of 
information through the API. 

Is SML a syntax, a data model, or what?


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



From robertl1 at home.com  Mon Nov 29 18:44:29 1999
From: robertl1 at home.com (Robert La Quey)
Date: Mon Jun  7 17:17:59 2004
Subject: Web Architecture
Message-ID: <3.0.6.32.19991129103710.03e2ae10@mail.dt1.sdca.home.com>

Hello,

As a proponent of SML and a relative unknown to this list I have
for the most part lurked for over six months now and tried to my 
homework like a good little boy. I am however a confirmed Simpleton,
both by bias and training (physics) and hence am fatally attracted to
Don Park's assault upon complexity. I had hoped to lurk and study
a bit longer but the pace of events demands I rush to publish. 

The main reason for SML is to provide a much more solid intellectual
foundation on which to build the higher level tools and abstractions
while at the same time maintaining continuity, if not compatibility,
with XML. In one sense SML is a crack in the wall of the entire edifice 
of Web Architecture which has been building up over the last few years. 
Surely an architecture this important deserves public discussion. 

The Web is too important to be left to the Experts. 

Dan Brickley provided a decent starting place for my education with 
several URLs. To wit:

	http://www.w3.org/TR/NOTE-rdfarch
	http://www.w3.org/TR/schema-arch
	http://www.w3.org/1999/04/WebData
	http://www.egroups.com/group/xml-dev/12791.html
	from which one is quickly led to the Dublin Core see:
	http://purl.oclc.org/dc/

Now one finds a large architectural edifice being 
implemented upon XML. My contention is that it is still
not too late to examine this entire edifice closely.

Is this architecture as elegant yet powerful as possible? 

Or is it full of kruft and legacy krusts as is XML? 

In a private message to Dan Bricker I asked,

>What is the architectural vision of the W3 for the World Wide Web
>and its future? I would like to see this stated as clearly and
>succintly as possible in one place. The Webdata article above 
>entitled 

>Web Architecture: Describing and Exchanging Data
>W3C Note 7 June 1999
>authored by Tim Berners-Lee, Dan Connolly and Ralph R. Swick 
>
>describes one such vision. The NOTE-rdfarch by Timbl shows the
>origins of this vision and puts it into a historic perspective. 
>

Does the unneeded complexity in XML continue to pollute 
the higher levels which accomodate themselves to XML as 
a foundation technology? or as I suspect 

Will starting from a simpler but equally general foundation
i.e. SML lead to a simpler and more general architecture? 

Or is it simply "too late" and do we have to live with what 
has been created by the W3 in closed WGs forever? 

<speculation>
XML smacks of an implementation that was begun and completed 
before the real goals were known. Either a lack of clarity 
in the founders' vision of	where to go from here or poor 
communication of that vision, perhaps induced by the massive 
political problems attendant upon such an effort lead to 
implementation is being worked on before the goals were clearly set.

Or perhaps the goals were clearly set but so dominated by 
the historic situation that it was difficult to see forward. 
</speculation>

Is the result, XML, a compromise and a bloat, actually in conflict 
with the construction of a simpler and more powerful higher level 
architecture? 

If true then how do we go forward? 

We need to understand "What" we are trying to do before
deciding "How" we are going to do it, although saddly, this 
is anot always a luxury we are afforded. This is a point 
that David Meggisson has refered to several times albeit
somewhat obliquely. The point of all of these exercises
is not just employment, intellectual stimulation and good
conversation but rather to build useful applications that
have value to others. Perhaps the W3 working groups have 
much greater clarity on these issues than does the XML-DEV 
but those WGs are unfortunately not open and hence I can 
only speculate. 

Does the open community think that it is obvious from the 
work product of the W3 WGs that they do have a very clear 
high level view of the problems to be solved?

Does the W3 have a clear vision of the future of the Web? 

Where is that best articulated for the Simpleton who would 
like to become less ignorant? 

So I would like to ask a simple basic question,
"What are we trying to do?" I will provide one
tentative answer (not intended as final or dogmatic,
based more on ignorance and bias than knowledge)
in an attempt to provoke response. 

Here is one Simpletons synopsis of the WebData article 
authored by Tim Berners-Lee, Dan Connolly and Ralph R. Swick 

<synopsis>
Layer Purpose                            Example/Description
3) application  				e.g. [PICS], [OCS], [RSS]

2) Resource Description Framework  	Dublin Core 
						Describes a particular choice of 
						data structures (property lists)
						to be used by applications

1) XML	or SML					ML used for data serialization 
						and transport

0) Namespaces					Unique way of identifying names
</synopsis>

My choice of putting Namespaces at the bottom is a guess but is 
if I correctly understand implicit in the Web Architecture being
proposed. If this is wrong please correct me. 

Tools, e.g. parsers, XSLT, (quite a long list) are then used with 
the components of these layers to aid in manipulation and transformation. 
The point of it all is to build useful applications. 

Immediately a question arises. 

Perhaps it is obvious that property lists are the best way to do
everything. That is less obvious to me. I have used many different 
data structures in my own programming efforts. Lists certainly 
have their purposes ... but only lists? I hate to think of representing
some things in lists. 

Does the use of RDF specialize the choice of data structures used 
by applications too soon? 

Are property lists the way to go? 

Another view, one I suspect (but am not yet prepared to
defend until death) would lead to a simpler core is: 

<synopsis>
Layer Purpose                            Example/Description
3) application  				e.g. [PICS], [OCS], [RSS]

2a) Resource Description Framework  	Dublin Core 
						Describes a particular choice of 
						data structures (property lists)
						to be used by applications
2b) Other Application Oriented Data Structures (or objectlets)

2) Object Definition				Standard way to represent objects
						in SML 

1) SML						ML used for data serialization 
						and transport and IDL

0) Namespaces					Unique way of identifying names
</synopsis>

There is certainly question as to whether the Object Definition should be
to one side and RDF is an application of OD. Other choices of fundamental 
data structure would be other apps of OD. 

Any actual choice or definition of these layers must be almost 
mathematical in its demand for simplicity and power. One must
refuse excess complexity as the cost of power. 

Is this a difficult quest? 

Certainly, but do not accuse, as some have done, the Simpletons of 
being lazy or script kiddies. Let's raise the tone of this discussion. 

One important use of SML will be as an Interface Definition Language (IDL) 
for and SML-RPC web of distributed objects ala Dave Winer and others
beautiful insight and work. This is aimed at replacing CORBA and DCOM
which also have major complexity problems. 

Has anyone defined a list define a list of applications e.g. 
SML<=>RDBMS mapping, PICS, etc and asked,

What are the common components that can be factored out 
and provided as general services available to the 
application builder?

How do we layer these onto SML? 

My contention is that the Model Splitting induced by the use of 
attributes in XML, as discussed by Didier PH Martin and further 
clarified by Clark C. Evans very interesting and accurate comments 
on recursion, is a "Bad Thing".  And further, that having a single 
low level data model i.e. SML is the "Good Thing". It is almost 
the same story as that of Copernicus and Ptolemy, and we know who 
got that right. 

"For knowledge add one thing everyday, for wisdom remove one." 
	passed to me by C. H. Ting 

It is time for removal. 

Cheers,


Bob La Quey

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



From KenNorth at email.msn.com  Mon Nov 29 18:48:47 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:59 2004
Subject: XML Database: position papers ?
References: <199911291735.SAA02223@chimay.loria.fr>
Message-ID: <014d01bf3a9a$b0ef2360$0b00a8c0@grissom>

From: Patrice Bonhomme <Patrice.Bonhomme@loria.fr>

> I am looking for some position papers that are doing a comparison of both
> relational model and object oriented approaches for XML database
conception.

You'll find some vendor white papers compare object and relational. If you
are interested in current technology, you should compare three data models
if your interest is XML:

relational (RDBMS), object-relational (ORDBMS), and object (ODBMS)

Examples of ORDBMS include Informix, Oracle, and IBM DB2.

There is also a group that can store Java objects (Java-relational
databases).




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



From KenNorth at email.msn.com  Mon Nov 29 19:07:46 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:17:59 2004
Subject: XML Database: position papers ?
References: <199911291735.SAA02223@chimay.loria.fr>
Message-ID: <016d01bf3a9d$5ceee5e0$0b00a8c0@grissom>

>
> I am looking for some position papers that are doing a comparison of both
> relational model and object oriented approaches for XML database
conception.

Not exactly a white paper, but if you want to hear XML architects from
Oracle, IBM, Informix and Microsoft discuss XML support in their servers,
browse to TechNetCast and listen to the XML One  panel discussion:

www.technetcast.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clark.evans at manhattanproject.com  Mon Nov 29 20:04:05 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:59 2004
Subject: Web Architecture
In-Reply-To: <3.0.6.32.19991129103710.03e2ae10@mail.dt1.sdca.home.com>
Message-ID: <Pine.LNX.4.10.9911290301370.2504-100000@cauchy.clarkevans.com>


On Mon, 29 Nov 1999, Robert La Quey wrote:
> Perhaps it is obvious that property lists are the best way to do
> everything. That is less obvious to me. I have used many different 
> data structures in my own programming efforts. Lists certainly 
> have their purposes ... but only lists? I hate to think of representing
> some things in lists. 

...

> My contention is that the Model Splitting induced by the use of 
> attributes in XML, as discussed by Didier PH Martin and further 
> clarified by Clark C. Evans very interesting and accurate comments 
> on recursion, is a "Bad Thing".  And further, that having a single 
> low level data model i.e. SML is the "Good Thing". It is almost 
> the same story as that of Copernicus and Ptolemy, and we know who 
> got that right. 

Robert,

Could you dive in two further detail here... this last
part went over my head a bit.

;) Clark


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



From clark.evans at manhattanproject.com  Mon Nov 29 19:58:52 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:17:59 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <199911290116.UAA25524@locke.ccil.org>
Message-ID: <Pine.LNX.4.10.9911290225570.2129-100000@cauchy.clarkevans.com>


  SML cannot drop attributes unless it provides
  a resonable alternative.

On Sun, 28 Nov 1999, John Cowan wrote:
> >     <element att="val"> <content/> </element>
> 
> How about this?
> 
> 	<element <att>val</att>> <content/> </element>
> 
> This is for sure not XML/SGML, but it generalizes the recursive
> pattern.  If you want an attribute on the attribute, you write:
> 
> 	<element <att <att-of-att>subvalue</att-of-att>>val</att>>  ...

Thanks John.  Didn't even think of this.  It would 
definately allow for recursive attributes -- and a 
clear distinction between meta informatoin (attributes) 
and content information.  Very nice.

Unfortunately, it breaks with XML compatibility...  thus, 
we are left with this question:

  Is having a syntax level distinction between information and
  information about the information (meta information) necessary?

I'm uncertain, but leaning towards "yes" for my vote.
IMHO, there is a huge difference between the two.

Take the following HTML fragment:

  <table border="2" cellpadding="50">
    <tr><td>One</td><td>Two</td></tr>
    <tr><td colspan="2">Three</td></tr>
  </element>

I clearly see the different role that content plays
as opposed to attributes. The border and cellpadding
attributes *modify* the state of the table; where
the tr element content is *part-of* the table.
The border attribute recurisvely applies to 
every one of the table's children by virtue
of how the table is drawn.  In a similar way, the 
colspan changes the last td element so that its 
funciton is completely different -- a child of td 
does not have this power.

On a side (but very important) note, the
attribute syntax allows all of these modifiers
to be expressed *before* the first element content.

>From a pratical sequential processing perspective,
this syntax distinction is very necessary -- 
otherwise one would have to wait until the entire
content of an element to be read "just-in-case"
one of the children modified its parent.  This
would be a nightmare, and would require random
access... hence more memory, and thus, completely
undermine SML's application to less powerful devices.

>From a philosophical perspective, the attributes
define the "whole", where the content defines
the "parts".  Mixing them leaves a nasty
taste in my mouth.

I assume there is a fundamental reason for
this seperation in SGML, and thus in HTML
and that it did not arrive by accident.
Could the above comments be part of the reason?

So.... 

SML cannot drop attributes *unless* is provides
an alternative approach.

This approach should support the attributes
(those things which apply to the whole) appearing
first, and the content occuring afterwords.

Ideally, the alternative approach would
allow for recursion as well... hence
John Cowan's suggestion is brilliant...

However, it's not XML compatible.

Is this *such* a big deal?  How hard
would it be to make a parser that could
handle both.... 

Best,

Clark




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.gotze at statskontoret.se  Mon Nov 29 20:09:50 1999
From: john.gotze at statskontoret.se (=?iso-8859-1?Q?G=F6tze_John?=)
Date: Mon Jun  7 17:17:59 2004
Subject: SV: RSS and WAP - another RSS question
Message-ID: <BFA943EA7C41D211976A0060087D1D375B8F18@mailsrv1.statskontoret.se>

Hi,

Oliver Becker [mailto:obecker@informatik.hu-berlin.de]:
> may someone give me a hint what RSS is an abreviation for.
...
> Weblinks for further reading welcome.

You can look in the XML/Syndication section at
http://www.links.gotzespace.dk

Cheers,
John Gotze

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 20:30:57 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:59 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.LNX.4.10.9911290225570.2129-100000@cauchy.clarkevans.
 com>
References: <199911290116.UAA25524@locke.ccil.org>
Message-ID: <3.0.6.32.19991129201316.00a17cd0@gpo.iol.ie>

>> 
>> 	<element <att>val</att>> <content/> </element>
>> 
>> This is for sure not XML/SGML, but it generalizes the recursive
>> pattern.  If you want an attribute on the attribute, you write:
>> 
>> 	<element <att <att-of-att>subvalue</att-of-att>>val</att>>  ...
>
>Thanks John.  Didn't even think of this.  It would 
>definately allow for recursive attributes -- and a 
>clear distinction between meta informatoin (attributes) 
>and content information.  Very nice.
>
<rant>
The notion that elements are for information and
attributes is, IMO, bogus.

Yes there are XML applications where attributes are
used to "talk about" elements but I have seen, and
created, many XML/SGML applications where this is
not so.
</rant>


regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 20:33:45 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:17:59 2004
Subject: (retry) Re: [SML] Whether to support Attribute or not?
Message-ID: <3.0.6.32.19991129201610.00a2a4f0@gpo.iol.ie>

[John Cowan]
>> 
>> 	<element <att>val</att>> <content/> </element>
>> 
>> This is for sure not XML/SGML, but it generalizes the recursive
>> pattern.  If you want an attribute on the attribute, you write:
>> 
>> 	<element <att <att-of-att>subvalue</att-of-att>>val</att>>  ...

[Clark C. Evan]
>
>Thanks John.  Didn't even think of this.  It would 
>definately allow for recursive attributes -- and a 
>clear distinction between meta informatoin (attributes) 
>and content information.  Very nice.
>
<rant>
The notion that elements are for information whilst
attributes are for meta-information is, IMO, bogus.

Yes there are XML applications where attributes are
used to "talk about" elements but I have seen, and
created, many XML/SGML applications where this is
not so.
</rant>


regards,

<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 20:50:01 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun  7 17:17:59 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <001601bf387c$0a812840$099918d1@docuverse1>
Message-ID: <3.0.1.32.19991129154643.00d054bc@tiac.net>

>  "Why should attributes be supported in SML?"

Because without them, it's not clear how I can point at something.

- SML should be useful for conveying "objects" (blocks of related data)
- Objects often reference one another ("pointing")
- You need a way to identify objects, so you can point to them

Example in XML:

<Thing id='foo' />

Now I can refer to "foo" or the "Thing called foo" or whatever is
appropriate in my application, and it's pretty clear in my language which
thing I'm referring to.

Sure, you can normalize this to:

<Thing>
 <Id>foo</Id>
</Thing>

But, well.... yuck.  This is just... strange.

Doesn't it strike you as perverse to dive into the sub-elements of an
element to get a handle to the parent?

-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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webMethods.com  Mon Nov 29 20:56:45 1999
From: jlapp at webMethods.com (Joe Lapp)
Date: Mon Jun  7 17:17:59 2004
Subject: [SML] Preliminary EBNF v0.2
Message-ID: <3.0.32.19991129155742.026439c0@nexus.webmethods.com>

At 03:59 AM 11/28/99 -0800, Don Park wrote:
>data ::= (element | CharData | CharCode)*
>element ::= StartTag data EndTag | EmptyTag

I assume that a document is an instance of element, right?  (Please say yes.)

>StartTag ::= '<' Name '>'
>EndTag ::= '</' Name '>'
>EmptyTag ::= '<' Name '/>'
>Name ::= NameChar+

We still need to be XML conforming, so we need a different first character.
 John Cowan has convinced me that subsetting Unicode for CharData doesn't
have to be a huge performance issue.  Let's not allow chars that XML does
not allow.

We should use the character productions defined in XML.  A bit more of a
headache for programmers, but nothing tough.

>NameChar ::= [^<>&] - (#x20 | #x9 | #xD | #xA)
>CharData ::= [^<>&]*
>CharCode ::= '&' ('#x' [0-9A-F]+ | 'lt' | 'gt' | 'amp') ';'

--
Joe Lapp                     (Looking for some good people to
Senior Engineer               help create XML technologies that
http://www.webMethods.com     connect businesses to businesses
jlapp@webMethods.com          over the web.)

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



From clark.evans at manhattanproject.com  Mon Nov 29 21:16:42 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <3.0.6.32.19991129201316.00a17cd0@gpo.iol.ie>
Message-ID: <Pine.LNX.4.10.9911290404550.2586-100000@cauchy.clarkevans.com>

On Mon, 29 Nov 1999, Sean McGrath wrote:
> The notion that elements are for information and
> attributes is, IMO, bogus.

I'm sorry. I don't understand what is bogus here.
Could you explain what you find so disturbing?
 
> Yes there are XML applications where attributes are
> used to "talk about" elements but I have seen, and
> created, many XML/SGML applications where this is
> not so.

In any given numerical analysis domain you don't 
always need to use the square root of -1.  And, in
some domains you can re-frame the problem to avoid
this "abominatoin".  However, there are many domains
in which the solution becomes horribly complicated
unless you use "complex" numbers.  It is funny how
a small increase in complexity at a fundamental layer
makes the algebra familar and comfortable at a higher
level...    

I'm not saying that this is a direct analogy, however,
there are domains which attributes are very useful
and mixing them with content seems very confusing.  
In any case, if SML were to drop attributes, and not
provide at least a non-recursive replacement, then
I think the solutions using the "simpler" standard
would be far more "complicated" than just using XML.

And, once again, I'm not sure at all about recursive
attributes... I'm just pointing out the possibility
and thinking out loud.  Sorry if this makes you unhappy.

Best wishes,

Clark





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



From jlapp at webMethods.com  Mon Nov 29 21:17:27 1999
From: jlapp at webMethods.com (Joe Lapp)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <3.0.32.19991129161824.02646ec0@nexus.webmethods.com>

Haven't heard from anybody on my attribute-value vs. content positioning:

  http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/1137.html

In any case, I see value to the end user in being able to succinctly
represent data using attributes.  Users want readable XML.  Although I'm
usually in the use-elements-not-attributes camp, it's not clear to me that
we should enforce this.  Not having attributes may cost SML significant
user base.

I only wish it were a syntactic trick and not also a semantic one.  I wish
XML had made the following two elements equivalent:

  <product><price>$1.00</price></product>

  <product price="$1.00"/>

Namespaces would have been simpler, users wouldn't have had to worry over
whether to design attributes or elements into the doctype, and supporting
technologies such as XPath would be more robust, as queries would then
survive syntactic changes in the underlying doctype.

Is there any way to fix this in SML?  Are we bound by semantic
compatibility with XML processors?

... plus we need a way to support XML namespaces (see that SML thread).
--
Joe Lapp                     (Looking for some good people to
Senior Engineer               help create XML technologies that
http://www.webMethods.com     connect businesses to businesses
jlapp@webMethods.com          over the web.)

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



From clark.evans at manhattanproject.com  Mon Nov 29 21:20:23 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <3.0.1.32.19991129154643.00d054bc@tiac.net>
Message-ID: <Pine.LNX.4.10.9911290418370.2586-100000@cauchy.clarkevans.com>

On Mon, 29 Nov 1999, Joshua E. Smith wrote:
> Sure, you can normalize this to:
>
> <Thing>
>  <Id>foo</Id>
> </Thing>
> 
> But, well.... yuck.  This is just... strange.
> 
> Doesn't it strike you as perverse to dive into the sub-elements of an
> element to get a handle to the parent?

Yes it does.  It also requires that the _entire_ element be read
in (till its end tag is encountered) just in the case that a child
provides details which modify the parent -- in this case, the
parent's identifier.


;) Clark




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 21:48:35 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: "Joshua E. Smith"'s message of "Mon, 29 Nov 1999 15:46:43 -0500"
References: <3.0.1.32.19991129154643.00d054bc@tiac.net>
Message-ID: <m3hfi5vukh.fsf@biff.bitsko.slc.ut.us>

"Joshua E. Smith" <jesmith@kaon.com> writes:

> >  "Why should attributes be supported in SML?"
> 
> Because without them, it's not clear how I can point at something.
> 
> - SML should be useful for conveying "objects" (blocks of related data)
> - Objects often reference one another ("pointing")
> - You need a way to identify objects, so you can point to them

Attributes are more semantic than syntactic.  You can use a schema
language to make sure information about the content is processed
before information that is the content.  Also, by removing the
dependence on syntax you also relax the idea that information may only
be one (information about the content) or the other (the content).

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us
  <http://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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 21:47:24 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun  7 17:18:00 2004
Subject: A call for reason
References: <000301bf3a6f$96de5fc0$099918d1@docuverse1>
Message-ID: <3842F494.F3673EDE@allette.com.au>


Don Park wrote:

> Net result is that SML data will be well-formed but invalid
> name error will not be reported.

Well formed as long as the document (or whatever they're now called) doesn't look like:

   This is a <size>big</size> waste of energy<period/>

Or have I misread the EBNF? The above is both legal and desirable, right?


--
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 21:52:42 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
References: <Pine.LNX.4.10.9911290418370.2586-100000@cauchy.clarkevans.com>
Message-ID: <3842F32F.22735DFF@cs.ucsd.edu>



"Clark C. Evans" wrote:
> 
> On Mon, 29 Nov 1999, Joshua E. Smith wrote:
> > Sure, you can normalize this to:
> >
> > <Thing>
> >  <Id>foo</Id>
> > </Thing>
> >
> > But, well.... yuck.  This is just... strange.
> >
> > Doesn't it strike you as perverse to dive into the sub-elements of an
> > element to get a handle to the parent?
> 
> Yes it does.  It also requires that the _entire_ element be read
> in (till its end tag is encountered) just in the case that a child
> provides details which modify the parent -- in this case, the
> parent's identifier.
> 

But every child provides details that modify the parent.
Consider this element:

<home>
	<zip>91111</zip>
</home>

And then the following element:

<home>
	<local_schools>
		<school>S1</school>
		<school>S2</school>
		...
	</local_schools>
</home>

Same problem here, right? Every child modifies the parent.
Should not these cases be all semantically equivalent?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From mpogue at apache.org  Mon Nov 29 22:26:02 1999
From: mpogue at apache.org (Mike Pogue)
Date: Mon Jun  7 17:18:00 2004
Subject: XML4J EA2 --> Xerces-J 1.0
Message-ID: <3842FC26.FEB568A4@apache.org>

David Brownell <david-b@pacbell.net> wrote:

> Re the Java version, the version in that article is still the latest
> commercially licensed version (2.0.15).  The review is not "out of
> date" even though IBM subsequently released a noncommercial "EA2".

> With the care IBM invested in ensuring that the "EA2" version not
> be licensed for products, it'd be inappropriate to review EA2 unless
> the 2.0.15 release gets withdrawn in its favor.

David,

	Something that you might not have been aware of:

	The Xerces-J parser (the Apache name for what IBM calls XML4J EA2) is
both compliant (including passing one test that we disagree with your
interpretation of the spec on), and is freely available.  Both source
code and binaries for Xerces-J version 1 are available at
http://xml.apache.org, with updates done frequently.

	IBM's XML4J EA2 parser was contributed to xml.apache.org a couple 
weeks ago, and it is available under the Apache Open Source license,
which permits redistribution of both source code and binaries (note that
redistribution of source is not allowed under the ProjectX parser
license.  The Apache license also does not require that developers
"deliver Modifications to Sun upon request", as is required by Sun.)

	I think you'll also find that Xerces-J is faster on initial DOM
creation (for example, parsing "ot.xml"), it is faster and consumes less
memory on subsequent DOM tree traversal, and it has a lot more features
(like DOM Level 2, SAX version 2, and initial XML Schema support),
compared to the ProjectX parser.  

	If you happen to also look at performance, be sure to measure the
"deferred" DOM for best performance (it uses slightly more memory to
gain in performance, but it's still less than ProjectX uses).

	Since the Xerces-J code (formerly XML4J) is now freely available for
commercial use, I think it's worth a look.  Let us know if you have any
problems running it (the developers at xml.apache.org will be happy to
fix them)!

Mike Pogue
(XML4J team at IBM, Xerces-J team at xml.apache.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 29 22:29:41 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <Pine.LNX.4.10.9911290404550.2586-100000@cauchy.clarkevans.
 com>
References: <3.0.6.32.19991129201316.00a17cd0@gpo.iol.ie>
Message-ID: <3.0.6.32.19991129221155.009624b0@gpo.iol.ie>

>On Mon, 29 Nov 1999, Sean McGrath wrote:
>> The notion that elements are for information and
>> attributes is, IMO, bogus.
>
[Clark C. Evans]
>I'm sorry. I don't understand what is bogus here.
>Could you explain what you find so disturbing?
> 
The notion that attributes are a fundamentally different
type of information is what I find disturbing. I mark up
a section of law like this:
<section n = "1">
<p>
This Act shall be know as ...
</p>
...
</section>

Now is the number 1 "about" the section? Yes. Is it
part of the content of the section? Yes. Is it somehow
intrinsically different from the text of the section?
I don't think so. To those who say attributes are
always meta-content I say this (with tongue in
cheek):-

	<element aboutelement="false"/>


[...]
>
>I'm not saying that this is a direct analogy, however,
>there are domains which attributes are very useful
>and mixing them with content seems very confusing.  

I agree they can be confusing to the human eye
but so too are CALS tables with all the end-tags!

Attributes are a form of markup minimization.
They are more pleasing to the eye in certain
situations. Easier to read and all that.

>In any case, if SML were to drop attributes, and not
>provide at least a non-recursive replacement, then
>I think the solutions using the "simpler" standard
>would be far more "complicated" than just using XML.
>
>And, once again, I'm not sure at all about recursive
>attributes... I'm just pointing out the possibility
>and thinking out loud.  Sorry if this makes you unhappy.
>
Apologies about the "harrupmph!" of the last posting.
Got a bit worked up. No offense intended.



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From dbowen at es.com  Mon Nov 29 22:32:30 1999
From: dbowen at es.com (dbowen@es.com)
Date: Mon Jun  7 17:18:00 2004
Subject: Linking a XML document to its schema
Message-ID: <C2AF2791F262D311BBD00008C7E67FB7761117@torino.corp.es.com>

> We are developing an application which will use XML as a syntax for
> communicating data between two parts of that application.
> 
> This XML uses a DTD, both for the (admittedly limited) validation it
> provides, and to supply default values for attributes, so the 
> receiving
> part of the application needs to be able to find the DTD 
> before it can make
> sense of the XML.
> 
...
> What should I do?  If I put:
> 
>    <!DOCTYPE Linestyle SYSTEM "file://C:/MyApp/MyApp.dtd">
> 
> in the file, the XML will be unusable on any machine which 
> happens to have
> installed my application in another directory.

We have run into a similar issue.  In our case, we are creating a new MS
Windows Application (not Web based at all), and using an XML based file
format.  We are using the MSXML parser to load in and validate documents
according to our schema (or DTD).  We wanted to keep our Schemas (or DTDs)
stored in a central location, and have the data files reference them no
matter where our application is installed (or where the OS is installed).

The best answer we've gotten for our case was to create a handler for our
own Asynchronous Pluggable Protocol.  In our case, a reference to the schema
(or DTD) would look like
"our-custom-protocol://Some/Path/in/the/Registry/CLSID".  We then have a
CLSID to a COM object that delivers the schema (or DTD) to the protocol
handler.  Since MSXML uses URL monikers, we can do this.  Its not completely
implemented yet, but that's the plan.

I realize that this is very Microsoft/Windows specific, but we haven't found
a better way yet.  Does anyone else use an XML based file format for a
normal desktop application?  If so, how do you handle centralizing your
schema(s) and DTD(s)?

Thanks,

Daniel Bowen
Software Engineer
Evans & Sutherland
dbowen@es.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From clark.evans at manhattanproject.com  Mon Nov 29 22:34:44 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <199911290044.QAA09683@avocet.prod.itd.earthlink.net>
Message-ID: <Pine.LNX.4.10.9911290451520.2586-100000@cauchy.clarkevans.com>



On Sun, 28 Nov 1999, Joe Lapp wrote:
> I understand the problem better after reading other people's responses.
> What threw me was the analogy to object data and behavior, which I don't
> think is the right analogy.

Yep.  data/behavior is not quite right.

To see this more clearly, I firmly believe
that before describing any XML model, the context 
or business purpose of the XML document must
be clearly aticulated.  Only with a fixed context
does the content vs attribute distinction make
itself clear -- different contexts have different
solutions.

Otherwise, it is much like a debate.  Here
the experienced debater first induces the 
opponent to make a statement X in a context A.
Then, he continues by slowly changing the context 
to B -- praying that the opponent does not notice 
the context switch.  Finally, she proceeds with 
a line of reasoning that eventually contradicts
assumptions in context A.  And, sure enough, 
the opponent's statement is contradicted
since it was not updated to reflect the new context.

> 
> In each of these example elements
> 
>   <lineitem><model>XYZ</model><quantity>3</quantity></lineitem>
>   <lineitem quantity="3"><model>XYZ</model></lineitem>
>   <lineitem quantity="3">XYZ</lineitem>
> 
> 'lineitem' has two properties: model and quantity.  It happens that in the
> last example the model is not labelled 'model'.  The label is missing,
> since strictly speaking XYZ is not the lineitem.

Context:  The user is reviewing an order form displayed as
          a grid on the screen.  The text shown to the
          user must be included in the XML file as well
          as the internal part numbers, etc. 

<order id="283382">
  <line id="28383" can-change="yes" unit-price="12.95" >
    <part model="XYZ">Rotor Blade, 3 inches</part>
    <quantity>3</quantity>
    <extended-price>$38.85</extended-price>
  </line>
  <line id="28384" can-change="no" >
    <part model="BBB" close-out="yes">DuchBoy Grass XL</part>   
    <quantity>1</quantity>
    <extended-price>$24.49</extended-price>
  </line>
  ...
</order>

In the above XML fragment, the information shown to the
user who is filling out the order is "content", and
information needed by the client application for proper
editing is "attributes".   Something like "can-change"
is a direct command... not to the shopper, but to
the shopping applicatoin, thus it is meta-information.

  Context:  A picker is going through a warehouse
            fulfilling an order; holding a wireless device.

<order id="283382" priority="2" >
  <cart>283382</cart>
  <pick-list>
    <item id="28384" >
      <bin>A23</bin>
      <part>BBB</part>
      <quantity>1</quantity>
    </item>
    ...
    <item id="28383">
      <bin>Z34</bin>
      <part>XYZ</part>
      <quantity>3</quantity>
    </item>
  </pick-list>
</order>

In this case, priority is a directive to the 
wiress device used to rank order fulfillment
list.  The ids are needed for a feedback-message
describing what was picked.  All other things
are displayed directly to the human doing the
picking.  Thus, there are two classes of information,
those directed at the device (priority/id) and
the remainder of the information directed to the
device's user.

I hope this makes sense.

> I'd argue that if an element has attributes in addition to text content,
> then the attributes together with the content define the element, and the
> content must therefore be yet one more property of the element.  The
> property simply has not been named.

This, I believe, is the InfoSet / Property Set perspective.
>From what I remember, the property un-named is called "content"
It does sound very resonable.

> You might consider that a shortcoming of XML.  By allowing attributes it
> allows elements to have unnamed properties. 
> I'm having troubl interpreting this as an advantage that attributes 
> give.  Were there never attributes, every property would have a label.
> (Unless there is  mixed content, which prompts my next thread...)
>
> I think the solution for SML/XML conversion is give this property an
> explicit name.

Hmm.  Sorry.  I didn't quite get it.

...

As a streach, lets use a form example.  The elements are
model the layout components.  Text content, means that the 
element shows that text to the user directly.   Sub-elmeents, 
mean that the component is a container and has children.  
Attributes are not shown to the user, they are only 
used to direct how the widget is displayed.

While the user interacts with the widgets, they
change the text content; however, the user does
not interact with the attributes.  Instead, the
attributes define how the user interacts with
the text content -- it is meta-data.

Hmm.  Oh well.

Clark


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



From clark.evans at manhattanproject.com  Mon Nov 29 22:45:36 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <3842F32F.22735DFF@cs.ucsd.edu>
Message-ID: <Pine.LNX.4.10.9911290537210.2586-100000@cauchy.clarkevans.com>



On Mon, 29 Nov 1999, Pavel Velikhov wrote:
> > > <Thing>
> > >  <Id>foo</Id>
> > > </Thing>
> > >
> > > But, well.... yuck.  This is just... strange.
> > >
> > > Doesn't it strike you as perverse to dive into the sub-elements of an
> > > element to get a handle to the parent?
> > 
> > Yes it does.  It also requires that the _entire_ element be read
> > in (till its end tag is encountered) just in the case that a child
> > provides details which modify the parent -- in this case, the
> > parent's identifier.
> > 
> 
> But every child provides details that modify the parent.
> Consider this element:
> 
> <home>
> 	<zip>91111</zip>
> </home>
> 
> And then the following element:
> 
> <home>
> 	<local_schools>
> 		<school>S1</school>
> 		<school>S2</school>
> 		...
> 	</local_schools>
> </home>
> 
> Same problem here, right? Every child modifies the parent.
> Should not these cases be all semantically equivalent?

If you have to "dig" into the contents to figure
out which "processing pipeline" the content is
placed on then you have effectively elminated
all hope of sequential processing.  Thus, you 
need random access to the information stream.
And hence, "large" memory requiremens, thus
undermining the apparant "simplicity" of SML.

Hope this explains my thoughts on it better.

Clark


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



From clark.evans at manhattanproject.com  Mon Nov 29 23:15:52 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <3.0.6.32.19991129221155.009624b0@gpo.iol.ie>
Message-ID: <Pine.LNX.4.10.9911290548120.2586-100000@cauchy.clarkevans.com>

On Mon, 29 Nov 1999, Sean McGrath wrote:
> The notion that attributes are a fundamentally different
> type of information is what I find disturbing. I mark up
> a section of law like this:
> <section n = "1">
> <p>
> This Act shall be know as ...
> </p>
> ...
> </section>
> 
> Now is the number 1 "about" the section? Yes. Is it
> part of the content of the section? Yes. Is it somehow
> intrinsically different from the text of the section?
> I don't think so. To those who say attributes are
> always meta-content I say this (with tongue in
> cheek):-
> 
> 	<element aboutelement="false"/>

Ok.  I just find the distinction useful for my
rather strained thought process.  Just for my 
articulation, I'd like to clarify how I see it.

First, something often ignored is context.  Without
a frame of reference there is no way to categorize
anything. So, I agree with your statement above about
no single a universal category for any one item.  However, 
I do find a simple binary split to give insight and act
as a great guide for organizing information:

   Attributes: 
 
     The rules, directives, instructions,
     which individually mean nothing in the 
     current context, but taken together give 
     structure to the element.  In particuar,
     these act as "instructions" to the 
     processor which acts on the xml, configuring
     the processor so that it knows how to 
     handle the incoming content.  This information
     is targeted at the target program, not
     the final consumer.

   Content: 

     Those components, which, in the current
     frame of reference, have individual value 
     and are seperable from the whole.  In 
     particualar, these act as "data" to the 
     processor -- the information to be processed.
     This inforamation is targeted to the 
     final consumer.

Anyway, to me the distinction is all too clear and 
it is also irritating when people don't seem to see
it as I do (perhaps this is immaturity).  However, 
I recognize that my description is far from perfect.

However, as the methodology has served me well,
wish to inform others of what I've learned from 
diligent reading and study of others.
 
> [...]
> >
> >I'm not saying that this is a direct analogy, however,
> >there are domains which attributes are very useful
> >and mixing them with content seems very confusing.  
> 
> I agree they can be confusing to the human eye
> but so too are CALS tables with all the end-tags!

Yep. I'm not so happy with <element <att>val</att> />
but this style of syntax does support a binary
decomposition of the information.   

How well such a thing would work really depends
on valid applications... how well it works in 
the real world.  
 
> Attributes are a form of markup minimization.
> They are more pleasing to the eye in certain
> situations. Easier to read and all that.

I tend to use them to support this particular
decomposition of the problem domain.  So far
it has proved to give nice rewards in reduced
complexity.  I'm still an XML "adventurer", so
we will see how sustaining the success is.

> >In any case, if SML were to drop attributes, and not
> >provide at least a non-recursive replacement, then
> >I think the solutions using the "simpler" standard
> >would be far more "complicated" than just using XML.
> >
> >And, once again, I'm not sure at all about recursive
> >attributes... I'm just pointing out the possibility
> >and thinking out loud.  Sorry if this makes you unhappy.
> >
> Apologies about the "harrupmph!" of the last posting.
> Got a bit worked up. No offense intended.

Same here.  ;)

Best,

Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 23:18:16 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun  7 17:18:00 2004
Subject: [SML] Whether to support Attribute or not?
References: <Pine.LNX.4.10.9911290537210.2586-100000@cauchy.clarkevans.com>
Message-ID: <3843066E.F9E8D5A3@cs.ucsd.edu>



"Clark C. Evans" wrote:
> 
> On Mon, 29 Nov 1999, Pavel Velikhov wrote:
> ? ? ? ?Thing?
> ? ? ?  ?Id?foo?/Id?
> ? ? ? ?/Thing?
> ? ? ?
> ? ? ? But, well.... yuck.  This is just... strange.
> ? ? ?
> ? ? ? Doesn't it strike you as perverse to dive into the sub-elements of an
> ? ? ? element to get a handle to the parent?
> ? ?
> ? ? Yes it does.  It also requires that the _entire_ element be read
> ? ? in (till its end tag is encountered) just in the case that a child
> ? ? provides details which modify the parent -- in this case, the
> ? ? parent's identifier.
> ? ?
> ?
> ? But every child provides details that modify the parent.
> ? Consider this element:
> ?
> ? ?home?
> ?       ?zip?91111?/zip?
> ? ?/home?
> ?
> ? And then the following element:
> ?
> ? ?home?
> ?       ?local_schools?
> ?               ?school?S1?/school?
> ?               ?school?S2?/school?
> ?               ...
> ?       ?/local_schools?
> ? ?/home?
> ?
> ? Same problem here, right? Every child modifies the parent.
> ? Should not these cases be all semantically equivalent?
> 
> If you have to "dig" into the contents to figure
> out which "processing pipeline" the content is
> placed on then you have effectively elminated
> all hope of sequential processing.  Thus, you
> need random access to the information stream.
> And hence, "large" memory requiremens, thus
> undermining the apparant "simplicity" of SML.
> 

Well, I don't agree with you on this point. I have been working
on a streaming query processor for XML for some time, and the
problem is just not there. Why is it a problem going into the
element one or two levels deep? Besides the chances that you will
encode all the information relevant to the query processor into
attributes is very small. Consider the example above with the
local schools: what if I want to select all homes that have
some specific school in their neighborhood? This information
cannot be encoded in the attributes, since its nested. But I
can still stream such queries, all I have to do is descend one
level into each element and the find the school that satisfies
the condition.

Regards,
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 23:29:16 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:18:00 2004
Subject: Fw: [SML] Streaming XML processing. ( Whether to support Attribute
 or not? )
References: <Pine.GSU.4.10.9911290137530.9457-100000@netcom9.netcom.com>
Message-ID: <011601bf3ac0$9970c6a0$5df5c13f@PaulTchistopolskii>



> As I see it, you'd need a way of giving names to path expressions and
> their result sets, and a way of making one path expression conditional on
> the success of another.  Thus a path expression that goes down the
> conceptual tree along the child:: axis, then back up the tree along
> Ancestor::, and then sideways along following-sibling could be replaced
> with three child::-only path expressions that would have to match in
> sequence (though not the same order as they would appear in the full XPath
> expression), each of which would "squirrel away" the conceptual nodes that
> matched.  The idea is to limit the "running storage" required to a stack
> of element names encountered along the current branch of the conceptual
> tree and the text content of the current element (along with any
> squirreled-away data).

To me the most critical thing in streaming  XML processing 
is do we allow 'look-forward' rules or all of our rules are 
'look-backward'. ( Yacc ).

Lets look at 2 'rules'.

1 "If B has parent A"  ...
2 "If A has a child B"  ...

They look very similiar, but actualy (2)  requires  DOM 
*or* it requires very tricky conversion of (2) into set of 
rules of form (1) - possible, but ... it's not a good task 
for a thin client,  I think.

Even it is possible to make that tricky transformation 
of 'look-forward' rules, I think that for the sake of 
streaming ( efficiency and embeddability) , the 'basic' 
streaming API should use only 'look-backward'  
( or 'look-up the tree'  ) rules.

So far I think everything was more or less OK with yacc 
for long years, so such a limitation is already tested
by many applications.
 
> An interesting question is whether a full XPath expression could be
> automatically decomposed into a sequence of "sequential-path" expressions.

I think this problem is comparable with converting 
look-forward rooles to look-backward  rules.

I would better not to support look-forward rules at all in 
the core API. If there would be another layer, doing such a 
magic - why not?

Rgds.Paul.

PS.  I was wrong saying that SXSLT should be easy to 
write - it could be streaming.  I was estimating 'just'  
simplified  XT.  I was not brave enoght ;-) No big 
inventions there at the moment, I think.




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



From clark.evans at manhattanproject.com  Mon Nov 29 23:35:53 1999
From: clark.evans at manhattanproject.com (Clark C. Evans)
Date: Mon Jun  7 17:18:01 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <3843066E.F9E8D5A3@cs.ucsd.edu>
Message-ID: <Pine.LNX.4.10.9911290618210.2586-100000@cauchy.clarkevans.com>

On Mon, 29 Nov 1999, Pavel Velikhov wrote:
> > If you have to "dig" into the contents to figure
> > out which "processing pipeline" the content is
> > placed on then you have effectively elminated
> > all hope of sequential processing.  Thus, you
> > need random access to the information stream.
> > And hence, "large" memory requiremens, thus
> > undermining the apparant "simplicity" of SML.
> > 
> 
> Well, I don't agree with you on this point. I have been working
> on a streaming query processor for XML for some time, and the
> problem is just not there. Why is it a problem going into the
> element one or two levels deep? Besides the chances that you will
> encode all the information relevant to the query processor into
> attributes is very small. Consider the example above with the
> local schools: what if I want to select all homes that have
> some specific school in their neighborhood? This information
> cannot be encoded in the attributes, since its nested. But I
> can still stream such queries, all I have to do is descend one
> level into each element and the find the school that satisfies
> the condition.

In the case you have mentioned, if the <home> to be presented 
exceeds the capacity of the input buffer, then it must be copied 
elsewhere until enough information is gathered to accept or 
reject it.  If the element in question is a top-level element,
and if its children are numerous or large, then a large portion
of the XML stream need be held in storage.  In any case, 
a large number of allocations/deallocations would occur if
the input buffer could not be leveraged.

What I would do in this case, is make hash values for
the possible schools, and put the hash values in the
attributes  -- as this information is intended for
the processor of the information and not for the end-user.
With this information, the memory requirements could be
dramatically reduced since only a small fraction of
the stream would have to be held in memory.  Best yet,
the attribute stream can now be discarded even if it
exceeds the input buffer.  I hope this explains where 
I'm coming from.

;) Clark



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 23:35:41 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:18:01 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16FE5@martinique>

> -----Original Message-----
> From: Clark C. Evans [mailto:clark.evans@manhattanproject.com]
> Sent: Monday, November 29, 1999 1:59 AM
> 
> 
>   Is having a syntax level distinction between information and
>   information about the information (meta information) necessary?
> 

Ok, but you get a cleaner formulation if you drop the language about
info/metainfo from your question.  None of that matters, since the issue is
purely syntactic - users can use the syntactic devices in whatever way they
choose.  So the question is really just whether or not we need two distinct
syntactic devices.  Doesn't even matter what they're called - in fact
calling them "foo" and "bar" syntax would probably clarify things, since
"attribute" and "element" carry lots of semantic freight on their own.  The
entire discussion about what attributes and elements "mean" is very
interesting but not terribly useful, since there is no need to define them
semantically.

My own opinion fwiw is that having two such devices is well worth it,
precisely because with them I can model ordinary intuitions about the world
- things and their properties.  Sometimes that might mean info and metainfo.
In any case, I don't think anybody will seriously argue against the
proposition that chopping the world into related things (structures) on the
one hand and properties (attributes) on the other is pretty dadgummed
useful.  My keyboard has a bunch of keys (structure), but it doesn't have
beige.  Obviously one can model beige as a thing it has, and in some cases
it may make sense to do so, but there will always be people and situations
where you want to model ordinary intuition, in which e.g. color is percieved
as a property of a thing.  Collapsing the syntax into a single abstract
structuring mechanism would just increase the distance between the language
syntax and ordinary discourse.

-gregg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Mon Nov 29 23:59:01 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:18:01 2004
Subject: [SML] Whether to support Attribute or not?
References: <Pine.LNX.4.10.9911290537210.2586-100000@cauchy.clarkevans.com>
 <3843066E.F9E8D5A3@cs.ucsd.edu>
Message-ID: <013901bf3ac5$6ae93560$5df5c13f@PaulTchistopolskii>


> > If you have to "dig" into the contents to figure
> > out which "processing pipeline" the content is
> > placed on then you have effectively elminated
> > all hope of sequential processing.  Thus, you
> > need random access to the information stream.
> > And hence, "large" memory requiremens, thus
> > undermining the apparant "simplicity" of SML.
> > 
> 
> Well, I don't agree with you on this point. I have been working
> on a streaming query processor for XML for some time, and the
> problem is just not there. Why is it a problem going into the
> element one or two levels deep? Besides the chances that you will
> encode all the information relevant to the query processor into
> attributes is very small. Consider the example above with the
> local schools: what if I want to select all homes that have
> some specific school in their neighborhood? This information
> cannot be encoded in the attributes, since its nested. But I
> can still stream such queries, all I have to do is descend one
> level into each element and the find the school that satisfies
> the condition.

This is exactly the point. Attributes kludge allows easier 
processing when the hierarchy has only one level and 
*only* in this situation. 

<foo><att>Attr</att></foo>    - when processing it with SAX 
no easy way to implement the 'look-forward' rule of kind 
'If foo  has a child ( property )  Attr'

<foo att="Attr"></foo>    - when processing it with SAX
it is easy to implement the 'look-forward' rule of kind 
'If foo  has a child ( property )  Attr'

As any other kludge, attributes kludge allows you 
to process some percent of more easily than
without that klugde.

Like any other kludge even  it gives you something, 
it costs something. 

I think what it gives is not worth what  it costs.  Your mileage 
may vary, but for sure there is no logical arguments here. 

" Does this kludge simplyfy some things?  - Yes it does. 
Does it makes some other  things harder? - Yes it does."  

What is more important? 

We can only guess, because if some developer is concentrated  
only on processing some simple XML documents with SAX - 
for sure Attributes kludge is very convinient. 

Developer who tries to invent the new XQL ( with updates ;-) 
may have another point of view on this subject. 
I don't know who is closer  to the 'truth' ;-)

Not talking about the changes one should make 
to the SAX handler ( XT stylesheet e t.c. ) in the situation
when something designed to be attribute turns into element.

Rgds.Paul.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 00:01:12 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:18:01 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16FE6@martinique>

> -----Original Message-----
> From: Sean McGrath [mailto:digitome@iol.ie]
> Sent: Sunday, November 28, 1999 3:49 AM
> >If you really want simplicity, why not make *all* the attribute names
> >explicit, instead of exempting only the generic identifier ("GI").
> ..snip..
> Turn it around for a moment. Think of it this way:
> 	1) elements are elements
> 	2) attribute values are kinda-sort elements except that they
> 	are constrained in various ways.

Beggin the question.  2 points deducted.  ;)

> Simplification:
> 	1) Make all attributes elements
> 
> Expressive power lost = 0
> 

Hm.  By my calculation, ExPow lossage = 50%.  I had a syntactic means of
expressing two different notions; now everything is one stew of elements.
I've lost the syntactic analog of what goes on in my itty bitty grey cell.

Most of the debate seems centered on what might make life easier for
software.  If that's the criterion, then no-atts wins by a mile.  But if the
criterion is making life easier for the writer/reader/designer of texts
(i.e. xml docs), then attributes are definitely in.

-gregg

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



From liamquin at interlog.com  Tue Nov 30 00:57:30 1999
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:18:01 2004
Subject: XML Database: position papers ?
In-Reply-To: <199911291735.SAA02223@chimay.loria.fr>
Message-ID: <Pine.BSI.3.96r.991129195221.25147C-100000@shell1.interlog.com>

On Mon, 29 Nov 1999, Patrice Bonhomme wrote:
> I am looking for some position papers that are doing a comparison of both 
> relational model and object oriented approaches for XML database conception.
I'm half way thruogh writing a book about using XML and databases...

A lot of what's best depends on who you have available, and on
your environment.

It's pretty hard to get good performance either way, although the
SQL/MM extensions to support nested tables will have a big impact as
the major vendors release them  Of course, if you don't need rollback,
MySQL is probably 2 orders of magnitude faster for most small to medium
sized projects.

Some of the OO vendrs such as ODI and Poet have XGML software that's
very much worth looking at.

In practice, though, ask yourself very careful questions before
doing anything more complex than having plain files, RCS or CVS, and
a CGI script or two :-)

Lee

-- 
Liam Quin, Barefoot Computing, Toronto;  The barefoot agitator
l i a m    at    h o l o w e b    dot    n e t
Ankh on irc.sorcery.net, http://www.valinor.sorcery.net/~liam/


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



From jlapp at webmethods.com  Tue Nov 30 00:56:58 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:18:01 2004
Subject: Fw: [SML] Streaming XML processing. ( Whether to support
  Attribute or not? )
In-Reply-To: <011601bf3ac0$9970c6a0$5df5c13f@PaulTchistopolskii>
References: <Pine.GSU.4.10.9911290137530.9457-100000@netcom9.netcom.com>
Message-ID: <199911300056.QAA03000@gull.prod.itd.earthlink.net>

At 03:22 PM 11/29/1999 -0800, Paul Tchistopolskii wrote:
>[...]
>To me the most critical thing in streaming  XML processing 
>is do we allow 'look-forward' rules or all of our rules are 
>'look-backward'. ( Yacc ). [...]

Yes, in terms of the events that XML parser APIs (eg. SAX) spit out, this requires additional "look-ahead" (at future events) to get the same data.  Yes, this will add some complexity to a solution that might otherwise have avoided such look-ahead.

But attributes do not prevent the requirement to do look-ahead.  My stream might be filtered on structured data, which attributes never represent.  Or it might be filtered on unstructured data which happened to be represented in element content.

The "look-ahead" that you already needed for non-attribute data solves your problem.  It does not require anything DOM-like.  A stateful SAX-based parse will work just fine.

>I would better not to support look-forward rules at all in 
>the core API. If there would be another layer, doing such a 
>magic - why not?

You still need this 'magic' in a stateful SAX parse to filter on non-attribute data.

My main attribute issues remain:

- Users want to use attributes to make documents easier to read.
- XML namespaces use attributes for namespace declarations.

And on the flip side:

- Treating attribute values and element content uniformly in layered technologies has caused me and continues to cause me quite a few headaches.  But I've argued that this is only because attributes were given semantic distinctions over element content, whereas I think they should have been just a syntactic shorthand for data that would also be valid in element content.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 01:03:44 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:18:01 2004
Subject: XML Schema One-day intensive tutorial
References: <f5b66ylgngg.fsf@cogsci.ed.ac.uk>
Message-ID: <3843172D.333A@hiwaay.net>

Henry S. Thompson wrote:
> 
> Don't miss this chance to pester one of the editors with
> your personal opinions about what is and isn't right about this
> important impending W3C recommendation.

Gotta have arrays in the data structures.  OTW, must 
recommend returning it as incomplete.  Thanks for the 
opportunity to pester.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 01:03:42 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:18:01 2004
Subject: DTD.com - new repository
References: <NBBBJPGDLPIHJGEHAKBAGEMOEHAA.martind@netfolder.com>
	 <3.0.6.32.19991128103545.00a0ab80@gpo.iol.ie>
	 <nnhfi5e0zp.fsf@sanna.lysator.liu.se> <v04220804b4686a02970f@[171.66.196.146]>
Message-ID: <384316AF.A1A@hiwaay.net>

Avi Rappoport wrote:
> 
>  From the Gilbane Report:
> 
> LUMERIA ANNOUNCES DTD.COM
> 11/22/99
> 
> Lumeria, an infomediary incubator, announced the launch of DTD.com, 

Good to see another one.

Does anyone else think it is better if each business 
has its own repository which negotiates strictly with the 
partners chosen by contract?

A schema server is no harder than what you do now.  It really 
is a service and it needs to identify its counterpart, find 
the relevant near siblings, then negotiate a common namespace 
declared as the ROA for the extents of the performance.  It 
also should declare the list of reliable components to be 
used (ensure stable relationships).

Better than letting BigBill and his competitors see too 
deeply into your processes.  CYA my friends, CYA.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 01:04:04 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun  7 17:18:01 2004
Subject: A call for reason
References: <000001bf3a38$18e7fea0$099918d1@docuverse1>
Message-ID: <384320F3.7BCD@hiwaay.net>

Don Park wrote:
> 
> >I'm learning through the grapevine that some people of
> >influence are opposed to the SML effort.

Don't listen to the press.  They neither take the time 
to figure out the truth nor need to.  :-)

> As the person who started the SML effort, I have this to
> say to them:
> 
> If you have concerns, please voice them and suggest ways
> to minimize your concerns.  Let us work together to
> prevent unnecessary conflicts.

Other than as an erudite intellectual exercise in reductionism, 
what organization with sufficient interest to exercise 
is expected to champion SML?  Again, there are no moral reasons
not to have XML replace SGML even if there are some objections 
to the telling of the tale, so SML can as well.  But selling 
burgled goods does require a crafty fence, so SML will require 
at least a Nokia or two to make it viable.  Got milk?

> Just remember that not all things are controllable and
> not all people can be influenced.  Killing all the
> butterflies in Peking will not rid Kansas of tornadoes.
> Let the butterfly be and hope it drops dead on its own
> in the winter.

If they do, will you be adding them as meat to the 
paper sandwich or pressing them between the pages?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Tue Nov 30 07:26:20 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:18:01 2004
Subject: Web Architecture
References: <Pine.LNX.4.10.9911290301370.2504-100000@cauchy.clarkevans.com>
Message-ID: <005401bf3aeb$b0e22740$29fbb1cd@tomshp>

From: Clark C. Evans <clark.evans@manhattanproject.com>

>>... And further, that having a single
> > low level data model i.e. SML is the "Good Thing". It is almost
> > the same story as that of Copernicus and Ptolemy, and we know who
> > got that right.
>
> Robert,
>
> Could you dive in two further detail here... this last
> part went over my head a bit.
>
> ;) Clark
>

Copernicus published a massive book advocating that all the planets,
including the Earth, traveled around the sun.  The previous gold standard,
Ptolemy's, had everything going around the earth with complex
circles-on-circles to make the orbits look more or less right.  It's
interesting, in the context of SML, that Copernicus actually came up with a
MORE complex system with MORE circles-on-circles, and it wasn't really more
accurate either.  The book was unreadable, and only Kepler was interested.
Without him, it wouldn't have gone anywhere.  Kepler got rid of the
complexity, discovered elliptical orbits, and even got better predictions.

Judging from some of the posts, maybe their authors think that the  XML WG
is like Copernicus and that Don, with SML, is more like Kepler???

<sorry reason="off topic"/>

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 07:47:06 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun  7 17:18:01 2004
Subject: Processing XML. RFC.
Message-ID: <01a901bf3ad8$cf433b60$5df5c13f@PaulTchistopolskii>


Hello.

    It is not about SML ;-)

    Let us think about some technologies people use to process  
    XML files. Simplified a bit.
    
    1.  SAX API  - streaming. 

            a. Dataflow is 'read-only'.  
            b. Processing Rules are very simple and callbacks usualy 
            don't care about what happens on 'level up',  what is the 
            hierarchy e t.c. Callback  receives the node ( and attributes ).
            Easy to use if your node has only attributes, but not 
            elements ;-)
            c. Processing Rules are hardcoded by developer.

    2.  DOM. Document eats the entire memory. ;-)

            a. Dataflow could be 'read-write'.
            b. Processing Rules could be much more complex, because 
            at any point it is possible to get information about the hierarhy, 
            what happens in some other nodes e t.c. 
            c. Processing Rules are hardcoded by developer.

            d. Some twist here is to consider DOM to be a 
            stream of serialized objects and then map those 
            objects into appropriate Java Classes. There is 
            some framework of this kind advertized as 
            'Say no to DOM'. Because it only simplifies the 
            code for accessing  the nodes , but gives no       
            big advantage with Processing Rules - it should  
            be considered to be just a twist.

    3.   XT.  Document eats the entire memory.

            a. Dataflow is 'read-only'. 
            ( I'm not talking about existing vendor-specific 
            extensions yet ).

            b. Processing Rules are cool.
            c. Processing Rules are not hardcoded.
                
    
    What looks missing to me is: 

    XT1        XT  + streaming and 
    XT2        XT  + dataflow is 'read-write' 

    Q0. Something tells me that because SAX and DOM are 2 different things - 
    XT1 and XT2 are also different things. Right ?

    Q1. I think XT and alikes are very close to become XT2, but they 
    are getting  there supporting  DOM as an output. 
    (Do they ?  I think XT does. ) 

    That means that we'l need to have 2 DOM Objects in the memory
    ( input and transformed output ).

    Could it be even possible to have only one DOM object in the 
    memory... Transformating 'itself' ...  ?

    Is there any idea or any effort in W3C to get  something  similiar 
    to 'read-write'  XSLT and if yes - maybe there is any URL there ?

    Q2. Maybe there is already something similiar to XT1 and/or  XT2  ?

    Q3. I could live with such XT1 / XT2 if they are not xml-ish, but I think 
    they should be ?

Rgds.Paul.




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



From robertl1 at home.com  Tue Nov 30 07:47:55 1999
From: robertl1 at home.com (Robert La Quey)
Date: Mon Jun  7 17:18:01 2004
Subject: Web Architecture
In-Reply-To: <005401bf3aeb$b0e22740$29fbb1cd@tomshp>
References: <Pine.LNX.4.10.9911290301370.2504-100000@cauchy.clarkevans.com>
Message-ID: <3.0.6.32.19991129223025.0406c970@mail.dt1.sdca.home.com>

At 11:30 PM 11/29/99 -0500, you wrote:
>From: Clark C. Evans <clark.evans@manhattanproject.com>
>
>>>... And further, that having a single
>> > low level data model i.e. SML is the "Good Thing". It is almost
>> > the same story as that of Copernicus and Ptolemy, and we know who
>> > got that right.
>>
>> Robert,
>>
>> Could you dive in two further detail here... this last
>> part went over my head a bit.
>>
>> ;) Clark
>>
>
>Copernicus published a massive book advocating that all the planets,
>including the Earth, traveled around the sun.  The previous gold standard,
>Ptolemy's, had everything going around the earth with complex
>circles-on-circles to make the orbits look more or less right.  It's
>interesting, in the context of SML, that Copernicus actually came up with a
>MORE complex system with MORE circles-on-circles, and it wasn't really more
>accurate either.  

A correct statement of the facts. A good review. 

>The book was unreadable, and only Kepler was interested.

Better say, the book was only readable by Keppler. An important distinction
which made a difference.  

>Without him, it wouldn't have gone anywhere.  Kepler got rid of the
>complexity, discovered elliptical orbits, and even got better predictions.
>

Correct ... but without Copernicus insight Keppler might not have ever made 
any sense of Tycho Brahe's data. 

Two ancient truths had to fall: 1) the earth is the center of the universe
and 2) circles are the perfect form.  Copernicus got the first one, Keppler 
the second. 

>Judging from some of the posts, maybe their authors think that the  XML WG
>is like Copernicus and that Don, with SML, is more like Kepler???

Yes, nice point, so we might say:

SGML:XML:SML <=> Ptolemy:Copernicus:Kepler

><sorry reason="off topic"/>

No reason to be sorry. Not really off topic. Thanks for improving on the 
original statement. Historical understanding of the great shifts in paradigms 
is the most pragmatic of understandings. Even the Cowardly Lion knows that. 

We shall get back to the nuts and bolts though if that is all this list will 
tolerate. 

In this vein, perhaps it is time to explore a cut down expat that defines SML 
by that most wonderfully pragmatic of means, i.e. SML is that variant of XML
which goes thru this specific code. Open source is wonderful as Saint IGNUcius
and Linus Torvalds have shown. 

expat is GPL right? We can all look at and modify the code. Beautiful
code too. I say why not try a little sexpat ;) That should save us from the 
threat of being perceived as Philosophers when we are in fact Simpletons. 


Bob La Quey

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



From mdash at techbooks.com  Tue Nov 30 08:13:38 1999
From: mdash at techbooks.com (Manoranjan Dash)
Date: Mon Jun  7 17:18:01 2004
Subject: unsubscribe
In-Reply-To: <006901bf3a84$ee812b80$3caebdcf@njoshi.lebanon>
Message-ID: <3.0.6.32.19991130102621.00839cd0@pinnacle.techbooks.com>

Unsubscribe




At 08:15 AM 11/29/1999 -0800, Rashmi Joshi wrote:
>Unsubscribe
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From eau at fast.fujitsu.com.au  Tue Nov 30 08:14:48 1999
From: eau at fast.fujitsu.com.au (Eric Ulevik)
Date: Mon Jun  7 17:18:02 2004
Subject: XML4J EA2 --> Xerces-J 1.0
References: <3842FC26.FEB568A4@apache.org>
Message-ID: <0dba01bf3b01$9e875aa0$edd2ac89@eaux>

From: Mike Pogue <mpogue@apache.org>
> The Xerces-J parser (the Apache name for what IBM calls XML4J EA2) is
> both compliant (including passing one test that we disagree with your
> interpretation of the spec on), and is freely available.  Both source
> code and binaries for Xerces-J version 1 are available at
> http://xml.apache.org, with updates done frequently.

I haven't seen any updates. Just the original release. Am I mistaken?

Thanks,

Eric Ulevik



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



From mdash at techbooks.com  Tue Nov 30 08:41:18 1999
From: mdash at techbooks.com (Manoranjan Dash)
Date: Mon Jun  7 17:18:02 2004
Subject: unsubscribe
Message-ID: <3.0.6.32.19991130140909.008f85e0@pinnacle.techbooks.com>

unsubscribe


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



From mp at ecs.soton.ac.uk  Tue Nov 30 09:33:01 1999
From: mp at ecs.soton.ac.uk (Mark Papiani)
Date: Mon Jun  7 17:18:02 2004
Subject: XML-to-Java Tools
Message-ID: <384399C7.5D370932@ecs.soton.ac.uk>

I am about to start an evaluation of available tools that can generate
Java classes from XML documents, preferably from XML DTDs. Can anyone
recommend useful tools for this purpose. We wish to make it easy for our
developers to generate/read/maintain XML documents from Java programs,
ideally by using classes and accessor/mutator methods to represent the
XML document.

I believe that XBeans from IBMs XML Productivity Kit for Java  (XPK4J)
accomplishes this, but would welcome any recommendations for other tools
that I should investigate.

Many Thanks,

Mark Papiani
Department of Electronics and Computer Science
University of Southampton
mp@ecs.soton.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From mp at ecs.soton.ac.uk  Tue Nov 30 09:52:11 1999
From: mp at ecs.soton.ac.uk (Mark Papiani)
Date: Mon Jun  7 17:18:02 2004
Subject: SAX Validation
Message-ID: <38439E45.206A3D2E@ecs.soton.ac.uk>

I believe that one of the advantages of SAX parsers is that they report
parsing events via callbacks and 
can consume far less memory than DOM based parsers that build an in
memory parse tree. 

My question has to do with when validation errors are reported by SAX
parsers. For example, if the closing tag of the root element is missing
from an XML document, would a SAX parser only report that the document
was invalid, after it had reported all the other valid parsing events
for the rest of the document?

Thanks,

Mark Papiani
Department of Electronics and Computer Science
University of Southampton
mp@ecs.soton.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 10:11:41 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:18:02 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <3.0.6.32.19991130095401.00a2ec90@gpo.iol.ie>

[Sean McGrath]
>> Turn it around for a moment. Think of it this way:
>> 	1) elements are elements
>> 	2) attribute values are kinda-sort elements except that they
>> 	are constrained in various ways.
>
>Beggin the question.  2 points deducted.  ;)
>
>> Simplification:
>> 	1) Make all attributes elements
>> 
>> Expressive power lost = 0
>> 
>
[Greg Reynolds]
>Hm.  By my calculation, ExPow lossage = 50%.  I had a syntactic means of
>expressing two different notions; now everything is one stew of elements.
>I've lost the syntactic analog of what goes on in my itty bitty grey cell.
>

Its down to the percieved fundamental different in types of
information. I don't believe it is real. Others do.
I understand what Clark Evans means about the importance
of context in framing the element/attribute "distinction"
and I think you are coming from a similar angle.

But hey, contexts change with each script I write to process
XML right? For example:-
	<dog type = "Alsatian">
		<p>This one is a real puppy.</p>
	</dog>

Lets say I want to sort dogs by breed. The above XML suits
my purpose well. If my authors think primarily in terms of
dog types, perhaps this suits them too.[1]

Lets say I want to harvest descriptions of dogs. For authoring and
script writing purposes I would prefer this:
	<dog desc = "This one is a real puppy" type = "Alsation"/>

So the ideal element/attribute carve-up of information depends
on the processing task. If the distinction is so ephemeral that
it changes with each of an infinity of different possible
processing tasks then is it really there at all?
Attributes are a convenience - not an epistomological
requirement.

>Most of the debate seems centered on what might make life easier for
>software.  If that's the criterion, then no-atts wins by a mile.  But if the
>criterion is making life easier for the writer/reader/designer of texts
>(i.e. xml docs), then attributes are definitely in.
>
Woa! Firstly, I am focused 100% on easy software in SML-Land. At
this level of an information architecture I don't give a flying
fig-roll about writers/readers/designers! If us software
types are worthy of the air we breath, they will never see this
stuff! SML (IMO) is unashamedly about making things drop-dead
easy for *software*. All the user convenience stuff gets
layered on top.

Secondly, I have *never* come across a writer who likes
attributes:-) I have just finished a book on XML processing
with Python that I wrote in XML using a combination
of Emacs and Wordperfect/XML. Total attribute count = 0.
Am I a freak?

regards,




<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webmethods.com  Tue Nov 30 10:22:12 1999
From: jlapp at webmethods.com (Joe Lapp)
Date: Mon Jun  7 17:18:02 2004
Subject: A call for reason
In-Reply-To: <384320F3.7BCD@hiwaay.net>
References: <000001bf3a38$18e7fea0$099918d1@docuverse1>
Message-ID: <199911300236.SAA21939@gull.prod.itd.earthlink.net>

At 06:57 PM 11/29/1999 -0600, Len Bullard wrote:
>[...] SML will require 
>at least a Nokia or two to make it viable.  Got milk?

Excellent point, and I'll take that as a call to change the approach.  Instead of starting from first principles to identify the 'simple' subset, we probably ought to empirically identify the 'simple' subset predominantly now in use.

That way, when we are done specifying it, we will instantly have a huge user base and countless proponents.  The goal is merely to have a label we can attach to the subset, having defined the subset, to promote the subset as the recommended way for a particular audience to use XML.

But we would have to identify the audience, and much as it might appeal to the SML opposition, the term 'simple' doesn't seem properly descriptive of this audience.  (Its good to throw a peanut now and then.)

I still think our audience is the 'data' audience more than the 'publishing' audience, and I recognize that there is a continuum between these extremes.  And perhaps there is some majority agreement on what 'simple' means.

And what would this buy us, once we've defined the subset and given it a label?  The following rights:

- The right to label applications as conforming to the subset, and many existing applications could immediately assume this label.  Conforming would refer to XML produced rather than to XML accepted, which could be more open.

- The right to teach the subset before teaching full XML.  Users learning to use a subset-compliant application know they need learn no more than the subset.

- The right to answer questions about abstruse XML features by saying, "Oh, you don't need to know that -- just learn the well-defined subset."

- The right to decline supporting full XML, since the fact that so many applications are already subset-compliant relieves the pressure.

- The right to never learn all the abstruse features of XML.  Did you know that '&lt;' and '&#60;' are not identical when they occur in an entity declaration, even though they are identical when they occur in element content?

And full XML will remain in full force where it is most useful -- on the 'publishing' side, where SGML remains the more complex alternative.

Again, although XML has more baggage than many applications need, it is still an amazing feat on the part of Jon Bosak and his team that XML came to be useful for such a wide variety of applications.  Many of us are deeply in their debt.
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 10:53:12 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:18:02 2004
Subject: A call for reason
In-Reply-To: <199911300236.SAA21939@gull.prod.itd.earthlink.net>
References: <384320F3.7BCD@hiwaay.net>
 <000001bf3a38$18e7fea0$099918d1@docuverse1>
Message-ID: <3.0.6.32.19991130103031.0092dca0@gpo.iol.ie>

[Joe Lapp]
>
>Again, although XML has more baggage than many applications need, it is
still an amazing feat on the part of Jon Bosak and his team that XML came
to be useful for such a wide variety of applications.  Many of us are
deeply in their debt.
>--
Here, here.

regards,



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



From sunker at telkom.net  Tue Nov 30 10:59:29 1999
From: sunker at telkom.net (sunker@telkom.net)
Date: Mon Jun  7 17:18:02 2004
Subject: XML for printing?
Message-ID: <61D3A6AB14FED211856500001C055D9633E037@FS01>

Hi all.,

Can the XML document used for printing ?

thanks.

http://www.geocities.com/researchtriangle/campus/7211
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2080 bytes
Desc: not available
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19991130/f91c425c/winmail.bin
From oren at capella.co.il  Tue Nov 30 11:00:24 1999
From: oren at capella.co.il (Oren Ben-Kiki)
Date: Mon Jun  7 17:18:02 2004
Subject: (retry) Re: [SML] Whether to support Attribute or not?
References: <3.0.6.32.19991129201610.00a2a4f0@gpo.iol.ie>
Message-ID: <0e9901bf3b20$5cf5ad20$4602a8c0@capella.co.il>

Sean McGrath <digitome@iol.ie> wrote:
> The notion that elements are for information whilst
> attributes are for meta-information is, IMO, bogus.

I'd like to second that. The distinction between "information" and "meta
information" is strictly application dependent, for the very same document.
For example, consider an HTML document.

For a audio-only browser, the texts - and only the texts - are the
"information". Note that some of this text is in attributes (alt="...").

For a graphic design tool, the layout is the "information". This is
definitely in attributes (width="...", not to mention style="..."). Note
that in this case, some tools might choose to ignore the text altogether.
For example, if one is designing a template into which some text will be
"poured" later.

A text retrieval engine might have a different notion - maybe similar to the
audio-only browser, but it would probably be interested in more "semantics"
which might be available in yet another set of attributes...

And, of course, there is your regular browser, for which _everything_ is
"information".

I don't see that one can firmly say "this is meta-information" and "this is
information". Look at it another way - if some data isn't "information" for
_some_ application, then it wouldn't have been included in the document in
the first place...

As for whether SML should contain attributes: the only good reason given for
them was improved performance. Let's examine the case of streaming SML XSLT
processor - presumably this is where the problems will surface. Suppose we
want to find all "tag"s with a given "id", and do something to its "sub-tag"
content. There are several alternatives:

1. No attributes, allow "forward rules" (Paul Tchistopolskii's terminology).
The document can be in any order, the stylesheet would look like:

<xsl:template match="tag[id='value']">
    <xsl:for-each select="sub-tag">
        ...
    </xsl:for-each>
</xsl:template>

This seems the cleanest approach, except that the processor would need to
buffer arbitrary amounts of data. Given advanced optimization, proper
document ordering, and knowledge of this ordering (as in the input DTD),
this could achieve the same effect as (3), greatly reducing buffering.

2. No attributes, disallow all "forward rules". We'd have to assume that the
document author was polite enough to specify the id "attribute" element
before any "content" element. The stylesheet would look like:

<xsl:template match="tag/id='value'">
    <xsl:for-each select="following-siblings::sub-tag">
        ...
    </xsl:for-each>
</xsl:template>

The document designer is responsible for ensuring that the order of elements
in the document is such that all required processing is possible. Of course,
the stylesheet writer could do some buffering himself:

<xsl:template match="tag">
    <xsl:assign name="id-of-tag" expr=""/>
</xsl:template>
<xsl:template match="tag/id">
    <xsl:assign name="id-of-tag" expr="."/>
</xsl:template>
<xsl:template match="tag/sub-tag">
    <xsl:if test="$id-of-tag='value'">
        ...
    </xsl:if>
</xsl:template>

This allows matching on more then one attribute but is cumbersome and there
would still be "impossible" stylesheets - unless one allows matching on
result tree fragments.

3. A combination; allow forward rules but still rely on document order. In
this approach, the trick is to avoid needless buffering of "sub-tag"
elements when the "id" element is missing or has the wrong value. This can
be done as follows:

<xsl:template match="tag[id='value']">
    <xsl:for-each select="sub-tag">
        ...
    </xsl:for-each>
</xsl:template>
<xsl:template match="tag/*"/>

The processor is "greedy" - it will use the first template that matches,
preferring "higher" ones. Therefore, "tag/id" would cause the first template
to trigger, while "tag/sub-tag" would trigger the second one. Since only one
template may match each input element (streaming!), "tag/sub-tag" would also
disqualify the first template from being considered further, canceling the
buffering.

I haven't figured out how this interacts with a template priority mechanism,
but it is clear that regardless of the exact rules, writing an efficient
stylesheet would be much trickier this way - and it still relies on the
document writer using proper ordering of the elements.

4. Allow attributes, disallow "forward rules" except for matching on an
attribute. The stylesheet would look like:

<xsl:template match="tag[@id='value']">
    <xsl:for-each select="sub-tag">
        ...
    </xsl:for-each>
</xsl:template>

In this scheme, attributes are simply text valued elements which will be
buffered by the processor. Note that this has nothing to do with semantics
(meta-information vs. real content). The document writer has to change the
type of some elements to attributes - a much worse pollution of modeling by
implementation issues then a simple reordering. Also note that this is a
weaker approach then (1) and (3), since only a single level of lookahead is
allowed.

5. Allow both attributes and "forward rules". The stylesheet could be either
like (1) or (4), depending on the document structure. In this scheme,
attributes are simple text valued elements which will (i) be buffered by the
processor, and more importantly (ii) match patterns on attributes would be
resolved before any content is seen. Here attributes are really just an
optimization hack, and there would be endless debates as to when one should
use them (that is, the existing situation).

I'm partial to (3), myself, while investigating the possibility that (1) can
be optimized to achieve the same effect. If we are going to rely on
optimization hacks, at least lets make them as unobtrusive as possible.

Have fun,

    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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 11:04:38 1999
From: ssahuc at imediation.com (Sebastien Sahuc)
Date: Mon Jun  7 17:18:02 2004
Subject: [SML] Whether to support Attribute or not?
Message-ID: <C10B7E3A3AC3D211804E0000B45EDA84404B27@mail.imediation.com>

> From: Clark C. Evans [mailto:clark.evans@manhattanproject.com]
> I do find a simple binary split to give insight and act
> as a great guide for organizing information:
> 
>    Attributes: 
>  
>      The rules, directives, instructions,
>      which individually mean nothing in the 
>      current context, but taken together give 
>      structure to the element.  In particuar,
>      these act as "instructions" to the 
>      processor which acts on the xml, configuring
>      the processor so that it knows how to 
>      handle the incoming content.  This information
>      is targeted at the target program, not
>      the final consumer.

I Completely agree with this guideline since I expect attribute to add
behaviours to elements. Indeed when you need some action to be
performed on behalf the element like making an element stateful
(ID="...") for further reference (IDREF="..."), or to differenciate
two elements with a -kind of CSS- 'class' atribute instead of
encapsulating these elements into other elements.
On contrary elements act as content.

>    Content: 
> 
>      Those components, which, in the current
>      frame of reference, have individual value 
>      and are seperable from the whole.  In 
>      particualar, these act as "data" to the 
>      processor -- the information to be processed.
>      This inforamation is targeted to the 
>      final consumer.
> 
> Anyway, to me the distinction is all too clear and 
> it is also irritating when people don't seem to see
> it as I do 

Not only irritating but also hazardous, since I agree I don't use that
much attributes, but when I do, it really makes sense to use them, and
removing support to attribute frightens me more than anything.

Seb

> I recognize that my description is far from perfect.



> 
> However, as the methodology has served me well,
> wish to inform others of what I've learned from 
> diligent reading and study of others.
>  
> > [...]
> > >
> > >I'm not saying that this is a direct analogy, however,
> > >there are domains which attributes are very useful
> > >and mixing them with content seems very confusing.  
> > 
> > I agree they can be confusing to the human eye
> > but so too are CALS tables with all the end-tags!
> 
> Yep. I'm not so happy with <element <att>val</att> />
> but this style of syntax does support a binary
> decomposition of the information.   
> 
> How well such a thing would work really depends
> on valid applications... how well it works in 
> the real world.  
>  
> > Attributes are a form of markup minimization.
> > They are more pleasing to the eye in certain
> > situations. Easier to read and all that.
> 
> I tend to use them to support this particular
> decomposition of the problem domain.  So far
> it has proved to give nice rewards in reduced
> complexity.  I'm still an XML "adventurer", so
> we will see how sustaining the success is.
> 
> > >In any case, if SML were to drop attributes, and not
> > >provide at least a non-recursive replacement, then
> > >I think the solutions using the "simpler" standard
> > >would be far more "complicated" than just using XML.
> > >
> > >And, once again, I'm not sure at all about recursive
> > >attributes... I'm just pointing out the possibility
> > >and thinking out loud.  Sorry if this makes you unhappy.
> > >
> > Apologies about the "harrupmph!" of the last posting.
> > Got a bit worked up. No offense intended.
> 
> Same here.  ;)
> 
> Best,
> 
> Clark
> 
> 
> xml-dev: A list for W3C XML Developers. To post, 
> mailto:xml-dev@ic.ac.uk
> Archived as: 
> http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on 
> CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 11:32:44 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:18:02 2004
Subject: (retry) Re: [SML] Whether to support Attribute or not?
In-Reply-To: <0e9901bf3b20$5cf5ad20$4602a8c0@capella.co.il>
Message-ID: <001c01bf3b26$7056dc80$ab20268a@pc-lrd.bath.ac.uk>

Oren Ben-Kiki wrote:
> As for whether SML should contain attributes: the only good
> reason given for them was improved performance. Let's examine the case of
> streaming SML XSLT processor

<snip!>

> The document can be in any order, the stylesheet would look like:
>
> <xsl:template match="tag[id='value']">
>     <xsl:for-each select="sub-tag">
>         ...
>     </xsl:for-each>
> </xsl:template>

Without wanting to detract from Oren's posting, or sound facietious...

In these examples it seems implicit that you're assuming that your
streaming XSLT processor uses an XML parser (or an SML parser
that supports attributes and namespaces) - as the XSLT examples
clearly use attributes.

If you're using an SML processor, then you can use XSLT if
it supports attributes and namespaces, if not then you'll need an revised
XSLT standard that doesn't use match="" or xsl:template.

So no attributes - no SML XSLT processor. You need S-XSLT.
No namespaces - no SML XSLT processor. You need S-XSLT.

If SML supports namespaces, and attributes, then you can
use XSLT. Assuming that SML 'bit-of-data' (its not a document)
has a document element (isn't that required for XSLT?). If SML
still supports the notion of no document element, then again
you need S-XSLT

Don't these knock-on effects on other standards smack of re-inventing
the wheel?

Or am I missing something here, and I've now got egg all over
my face?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 11:40:33 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun  7 17:18:02 2004
Subject: Still news
Message-ID: <8DCB90532FF7D211B34400805FD48853B22A17@SENMAIL3>

Amazing what the Queen knows about E-Commerce....
wonder if she's available for hire?

In fact, why don't all politicians run the Internet as they know so much
about it?

These people are causing serious problems especially in the UK. 
I wish they would just let peole innovate before the entire opportunity is
lost.

Cheers
Steven

Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280

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:	Francis Norton [SMTP:francis@redrice.com]
> Sent:	29 November 1999 18:03
> To:	John Tigue
> Cc:	xml-dev
> Subject:	Re: Still news
> 
> Pretty much the same thing looks like happening here in the UK, minus
> some unpleasant baggage that threatened to derail the whole proposal. 
> 
> http://www.fipr.org/uk_ecomm_bill/qupr.html
> 
> Francis.
> 
> John Tigue wrote:
> > 
> > While we're talking news, I think the following will
> > be very significant for XML:
> > 
> > http://news.cnet.com/news/0-1005-200-1454205.html
> > 
> > Senate approves slimmed-down digital signature bill
> > 
> > WASHINGTON--The Senate unanimously approved legislation
> > to promote e-commerce by giving contracts signed in a
> > digital format the same legal standing as the
> > ink-and-paper kind.
> > 
> > -John
> > 
> > Tim Bray wrote:
> > > XML is the cover story on PC week; coverage effusive
> > > even by the standards we've started getting used to.
> > > Check out http://www.zdnet.com/pcweek/
> > >
> > > -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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Nov 30 11:48:11 1999
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon Jun  7 17:18:02 2004
Subject: Still news
In-Reply-To: <8DCB90532FF7D211B34400805FD48853B22A17@SENMAIL3>
References: <8DCB90532FF7D211B34400805FD48853B22A17@SENMAIL3>
Message-ID: <14403.47318.664476.484117@spqr.oucs.ox.ac.uk>

Steven Livingstone, ITS, SENM writes:
 > These people are causing serious problems especially in the UK. 
 > I wish they would just let peole innovate before the entire opportunity is
 > lost.

We must also make sure that no obstacles are put in the way of
people introducing genetically modified crops, of course. Decisions
about human cloning should be left to responsible scientists. And
everyone should be allowed to carry a gun for self defence. Dang that
Queen, standing in the way of progress.

Sebastian


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 12:00:35 1999
From: oren at capella.co.il (Oren Ben-Kiki)
Date: Mon Jun  7 17:18:02 2004
Subject: (retry) Re: [SML] Whether to support Attribute or not?
References: <001c01bf3b26$7056dc80$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <0ed001bf3b28$c55b5150$4602a8c0@capella.co.il>

Leigh Dodds <ldodds@ingenta.com> wrote:
> Without wanting to detract from Oren's posting, or sound facietious...
>
> In these examples it seems implicit that you're assuming that your
> streaming XSLT processor uses an XML parser (or an SML parser
> that supports attributes and namespaces) - as the XSLT examples
> clearly use attributes.

I wanted to discuss the semantics of S-XSLT (or SSLT), so I stuck to the
known XSLT syntax. Naturally, if SML did not provide attributes, _and_ if a
separate SSLT language was to be used, then it too would avoid attributes.
It isn't yet clear that SSLT is viable, even assuming SML is. We might
settle on simply using XSLT on SML input.

> ... Don't these knock-on effects on other standards smack of re-inventing
> the wheel?

Well, in SSLT you could make a good case for simply using XSLT "as is".
There's no reason we _must_ write the stylesheets in SML. I personally would
not be interested in a separate SSLT spec unless it provided some advantage
over XSLT - such as streaming. Just switching syntax from XML to SML isn't
worth it.

Other XML specs don't have this option. How would one handle XLink in SML?
Obviously not by using an "href" attribute, if attributes are not
supported... Maybe we could set up a standard conversion from XML specs to
SML specs. I assume it is agreed that SML does need something like XLink...

> Or am I missing something here, and I've now got egg all over
> my face?

No, that's a perfectly good question, and why some people doubt that SML is
useful in the first place. SML does not claim to cover any new ground, just
as XML didn't when compared to SGML. At this point, either you buy the
notion that the XML specs are too complex or you don't.

Have fun,

    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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 11:59:56 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:18:03 2004
Subject: SAX Validation
In-Reply-To: Mark Papiani's message of "Tue, 30 Nov 1999 09:52:05 +0000"
References: <38439E45.206A3D2E@ecs.soton.ac.uk>
Message-ID: <m3k8n0jinz.fsf@localhost.localdomain>

Mark Papiani <mp@ecs.soton.ac.uk> writes:

> I believe that one of the advantages of SAX parsers is that they report
> parsing events via callbacks and 
> can consume far less memory than DOM based parsers that build an in
> memory parse tree. 
> 
> My question has to do with when validation errors are reported by SAX
> parsers. For example, if the closing tag of the root element is missing
> from an XML document, would a SAX parser only report that the document
> was invalid, after it had reported all the other valid parsing events
> for the rest of the document?

That really depends on the parser -- it has to report the error some
time before the endDocument() event, but when it does so depends on
the implementation.  If (for example) your parser builds an in-memory
tree first and then walks through it or if it buffers part or all of
the event stream, it might report the error immediately after the
startDocument() event.  Typically, though, the parser will deliver
events as it finds them, so you won't find out about the problem until
near the end.

By the way, the missing tag is a well-formedness error, so SAX parsers 
will use fatalError() rather than error() to report it.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 12:12:35 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:03 2004
Subject: A call for reason
In-Reply-To: <199911300236.SAA21939@gull.prod.itd.earthlink.net>
Message-ID: <000401bf3b2c$89f07420$099918d1@docuverse1>

>Excellent point, and I'll take that as a call to change the 
>approach.  Instead of starting from first principles to 
>identify the 'simple' subset, we probably ought to empirically 
>identify the 'simple' subset predominantly now in use.

Joe,

I like this line of thinking and would like to see it
progress further.  Result should hopefully be a list
of firmer goals/requirements.

Everyone who are interested in SML are here mainly because
of its relationship to XML.  SML discussions have been
drifting somewhat away from XML so I would like to see
if this thread will help us get back to the original intent:
SML is a subset of XML.

Lately, I have been trying to gain a different perspective
by thinking what if SML was here first and XML was actually
SML 2.0?  This line of thinking adds a rather interesting
appreciation of attributes.

I hope you don't mind if I stay back in the background for
a while to observe because I found it rather difficult to
see things objectively while trading blows at the frontline.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 12:20:49 1999
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:18:03 2004
Subject: Web Architecture
References: <3.0.6.32.19991129103710.03e2ae10@mail.dt1.sdca.home.com>
Message-ID: <3843C1DA.82DC47AA@mecomnet.de>

Robert La Quey wrote:
> 
> 
> Here is one Simpletons synopsis of the WebData article
> authored by Tim Berners-Lee, Dan Connolly and Ralph R. Swick
> 
> <synopsis>
> Layer Purpose                            Example/Description
> 3) application  
> 2) Resource Description Framework  
> 1) XML  or SML 
> 0) Namespaces                                   Unique way of identifying names
> </synopsis>
> 
> My choice of putting Namespaces at the bottom is a guess but is
> if I correctly understand implicit in the Web Architecture being
> proposed. If this is wrong please correct me.
> 

Most contributors would switch the entries in positions 1 and 0.

If you expand "namespaces" to "0) Names and Data", while you would be working
towards a simpler model, if you were to insist on a complete and consistent
realization of that model, you would need not only to set aside numerous
features of xml, but to disavow them and to the extend that they contradict,
to promote a non-conforming implementation.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 12:24:56 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun  7 17:18:03 2004
Subject: (retry) Re: [SML] Whether to support Attribute or not?
In-Reply-To: <0ed001bf3b28$c55b5150$4602a8c0@capella.co.il>
Message-ID: <001e01bf3b2c$b9f98300$ab20268a@pc-lrd.bath.ac.uk>

> It isn't yet clear that SSLT is viable, even assuming SML is.

>From the XML.com article:
"Since a Simple Markup Language is already a reality in many applications,
there is some urgency to setting the standard in place. Such a standard is
not
likely to be difficult to define, nor is there good reason for it to be
particularly controversial, so it should not take long for it to appear.
Expect to see the draft no later than mid-December and a standard by
January."
http://www.xml.com/pub/1999/11/sml/index.html

Until I read that, I thought SML was (largely) a research exercise on
Don's part - and we were all waiting to see whether he'd have to
eat the spec for breakfast or not. Will it or won't it fly. The
above quote suggests that it will, and that its actually going
to be a standard.

> We might settle on simply using XSLT on SML input.

> There's no reason we _must_ write the stylesheets in SML.

This is the nub of my confusion - if SML is for palmtops
or other devices, then we must write the stylesheets
in SML because such devices apparently can't cope with
an XML parser (and certainly not an XML parser for XSLT processing,
and an SML parser for the rest).

But then we're still not entirely sure where (or if) SML is going to
be deployed.

> Other XML specs don't have this option. How would one handle XLink in SML?

And what about XPath - the attribute related syntax might be redundant
if that removed from SML, so we can start simplifying there too, right?

I'm not knocking the SML effort per se, just trying to get a feel
for the scope of the endeavour. Its also hard to judge its progress
because there are no use-cases, milestones or requirements to
judge it against.

There are multiple definitions of 'simple'. Which one, specifically,
is SML working towards? Don suggested "minimal, and easy"
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/1163.html
Can we quantify that further - or will that happen when
the grammar has been finalised?

Cheers,

L.

p.s. Egg/face interface ready, as is my flame-proof jacket :). I'm
really just curious...


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



From mdash at techbooks.com  Tue Nov 30 12:37:57 1999
From: mdash at techbooks.com (Manoranjan Dash)
Date: Mon Jun  7 17:18:03 2004
Subject: unsubscribe
Message-ID: <3.0.6.32.19991130180449.008147d0@pinnacle.techbooks.com>

unsubscribe


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 12:41:55 1999
From: philipnye at freenet.co.uk (Philip Nye)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML] Whether to support Attribute or not?
References: <Pine.LNX.4.10.9911290225570.2129-100000@cauchy.clarkevans.com>
Message-ID: <3843C632.6599D41F@freenet.co.uk>

"Clark C. Evans" wrote:
> 
>   SML cannot drop attributes unless it provides
>   a resonable alternative.
...
> I clearly see the different role that content plays
> as opposed to attributes. The border and cellpadding
> attributes *modify* the state of the table; where
> the tr element content is *part-of* the table.
> The border attribute recurisvely applies to
> every one of the table's children by virtue
> of how the table is drawn.  In a similar way, the
> colspan changes the last td element so that its
> funciton is completely different -- a child of td
> does not have this power.

You are basing all your arguments on the _convention_ you like to use
for what goes in attributes and what in elements (meta-info in
attributes, info in elements). There is no requirement in the syntax for
this usage.

If you say that with SML you will feel obliged to devise a similar
convention for making semantic distinctions that is fine, but as it is
items are often made attributes or elements for silly processing reasons
and not for semantic ones at all.

i.e. If you want to be able to specify a set of alternative tokens, or a
default value, use an attribute. If you want a structured value use an
element. This is nothing to do with semantics.

Furthermore, why should meta-info be forced to be unstructured? - the
answer is that it isn't. When you need structured meta-info you just
break your attribute/element convention and probably no-one notices. It
certainly does not break anything in XML.

Dropping attributes entirely removes the artificial distinctions and
places the responsibility on the schema - but only in applications where
there is a distinction to be made.

An alternative is to make
<foo bar="xyz">...
equivalent to and freely interchangeable with
<foo><bar>xyz</bar>...

This gives the advantages of readability and allows you to apply similar
conventions if you want to.

> >From a pratical sequential processing perspective,
> this syntax distinction is very necessary --
> otherwise one would have to wait until the entire
> content of an element to be read "just-in-case"
> one of the children modified its parent.  This
> would be a nightmare, and would require random
> access... hence more memory, and thus, completely
> undermine SML's application to less powerful devices.

This is just not true - it all depends on the schema you are using
(whether defined in a formal schema language or otherwise). In terms of
simple text scanning the only requirement is that the modifying
"meta-info" element appears before the data or "info" element. This can
be made a requirement in the schema and it would seem an obvious thing
to do in some cases. I could equally say that allowing elements means I
have to assign a far bigger memory space to process my opening tags
since they could have several kilobytes of name-value attribute pairs
embedded in them.

Philip Nye

-- 
Philip Nye
Engineering Arts
72 Herberton Road  ~  Bournemouth  BH6 5HZ  ~  UK
tel +44 (0)1202 418236  ~  fax +44 (0)1202 418676
mailto:philipnye@freenet.co.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 13:04:13 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML] Whether to support Attribute or not?
In-Reply-To: <3.0.6.32.19991130095401.00a2ec90@gpo.iol.ie>
Message-ID: <000601bf3b33$bb4cb2c0$099918d1@docuverse1>

I don't think I have expressed my own opinion on this
issue so here it is:

1. Attributes are syntactic illusions.

They appear to be part of an element simply because
they are inside the brackets.  Child elements
are not and thus seem to represent containment.
This doesn't mean attributes are not useful however
since there are useful illusions, but they are
useful to people and not necessarily to machines.

Attributes are convenient in the same sense that
C is more convenient than assembly language.  Like
the 'for' loop, it is a shorthand for a common
usage pattern.

2. Attributes are double-edged swords.

After rather long discussions on the advantages and
disadvantages of attributes, I don't think there is
a need for me to explain this.

3. Attribute support is the key issue for SML.

While removing attributes opens up a new world of
possiblities, it also means SML users might have to
rebuild much of the stack of standards W3C and other
organizations have built because most of them uses
attributes.

It is true that the rebuilding will proceed faster because
we will have existing work to start with.  What I do not
know is if there is sufficient will to do this.  S-XSLT is
reachable, S-DOM is also reachable.  What about beyond?

Ultimately, the question of attribute support in SML is
a loaded one.  If we do not support attributes, we face
a lot of work ahead and competition with XML.  If we do
support attributes, we might not be different enough from
XML to survive on its own.  Tough choice.

We must think on this.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 13:09:28 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML] Preliminary EBNF v0.2
Message-ID: <199911301305.NAA13934@nag.co.uk>



> CharData  ::= [^<>&]*

What is your base character set from which you are removing the special
characters. It isn't clear to me whether you were intending just ascii
characters or all XML characters (up to #10FFFFFF) or all UCS-4
characters.

If you are allowing non ascii characters why do you allow
CharCode ::= '&' ('#x' [0-9A-F]+
it is superfluous to allow `&#xA4;' if you can enter the character `$'
directly, and the same for any other unicode character. You only need
the &#x notation if you intend to keep the character data 7 bit.

This is not a rhetorical question, I can't tell which you intend
from your description.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 13:21:31 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML] Preliminary EBNF v0.2
In-Reply-To: <199911301305.NAA13934@nag.co.uk>
Message-ID: <000b01bf3b36$2a2c91e0$099918d1@docuverse1>

>> CharData  ::= [^<>&]*
>
>What is your base character set from which you are removing the special
>characters. It isn't clear to me whether you were intending just ascii
>characters or all XML characters (up to #10FFFFFF) or all UCS-4
>characters.
>
>If you are allowing non ascii characters why do you allow
>CharCode ::= '&' ('#x' [0-9A-F]+
>it is superfluous to allow `&#xA4;' if you can enter the character `$'
>directly, and the same for any other unicode character. You only need
>the &#x notation if you intend to keep the character data 7 bit.

Encoding issue has not explored fully yet but
I do not see any possibility of SML supporting
only ASCII.

I do not think it is superflous to allow &#xA4;.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 13:28:07 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:03 2004
Subject: (retry) Re: [SML] Whether to support Attribute or not?
In-Reply-To: <001e01bf3b2c$b9f98300$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <000e01bf3b37$14cecb00$099918d1@docuverse1>

>I'm not knocking the SML effort per se, just trying to get a feel
>for the scope of the endeavour. Its also hard to judge its progress
>because there are no use-cases, milestones or requirements to
>judge it against.

Use-cases, milestones, and requirements are not there yet because
it is still early.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From tpassin at idsonline.com  Tue Nov 30 13:34:18 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:18:03 2004
Subject: A call for reason
References: <000401bf3b2c$89f07420$099918d1@docuverse1>
Message-ID: <004701bf3b38$2003f1c0$92fbb1cd@tomshp>

Don Park wrote:
> ...
> Lately, I have been trying to gain a different perspective
> by thinking what if SML was here first and XML was actually
> SML 2.0?  This line of thinking adds a rather interesting
> appreciation of attributes.
> ...
> Don Park

I'm starting to like Don's thinking here.  What a neat idea!  But there is
one thing against the notion, which probably is responsible for  a lot of
the desire for an SML.  XML has got some historical baggage.  If it were
really SML 2.0, SML 1.0 would have had the same baggage.  But it seems that
the baggage is what people want to eliminate.

Entities are an example.  You could replace &lt;, &amp;, and the rest with
some escape mechanism (like the backslash, I don't mean CDATA), and get rid
of all other entity types.  That would probably simplify things.  But then
you aren't a subset of XML anymore.  On the other hand, if you omit DTDs,
you could still be a subset.  I don't sense a consensus on the importance of
being a subset of XML, but I don't think things can really go anywhere until
this is pretty well settled (to first order, anyway).  Look at the number of
arguments about attributes that are being posted.  The people who actually
write parsers have been saying that there is virtually no cost in memory or
complexity to having attributes.  There's obviously a lot of people who find
them useful.  I think that anyone who sees an attribute in HTML for the
first time understands how to use them and their syntax.  It doesn't confuse
anything to have attributes. So leave them in and move on!

Regards,

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 13:51:47 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML] Without attrs, you don't need empty elements...
Message-ID: <3.0.1.32.19991130084541.00d090ac@tiac.net>

Maybe I'm just slow on the uptake, but I suddenly realized that if SML
omits attributes, there's not likely to be a need for empty elements.

(Scan your favorite XML sources and see how often there are empty elements
with *no* attributes.)

Dunno if that makes much difference in the parser, or even in user
understandability (having both <Foo></Foo> and <Foo /> available might
offend Occam), but it's interesting how one simplification can naturally
lead to another...


-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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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.aldridge at informatix.co.uk  Tue Nov 30 13:58:28 1999
From: john.aldridge at informatix.co.uk (John Aldridge)
Date: Mon Jun  7 17:18:03 2004
Subject: SML - a vote against
Message-ID: <3.0.6.32.19991130135751.00a155a0@mailhost>

Here's my take on the SML debate...

XML has been designed to be flexible enough to cover a wide range of
application domains, and to be broadly compatible with some existing
practice in this arena.  In reaching this design, compromises had to be
reached between simplicity and this flexibility and compatibility.

We probably all have quibbles about the wisdom of some of the compromises
reached; but on the whole, I suggest that a good balance has been reached
between addressing the needs of a broad range of applications, and keeping
the standard simple enough to be managable.

There will certainly be many applications for which this full flexibility
is not required; and similarly many applications where compatibility is not
an issue.  The question is whether, for these applications, the penalties
of using XML as it stands are large enough to warrant not using it.

The benefit of a single standard is that we will all profit from a rapid
proliferation and deployment of tools which operate on information
conforming to this standard.  Every division in the standard dilutes this
benefit.

The disadvantage is that applications have to carry the implementation
costs of features which they do not use.

In the end, I think this is a case where be benefits of a single standard
comfortably outweigh the costs.  Let's stick with the one we've got.
-- 
Cheers,
John

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



From tpassin at idsonline.com  Tue Nov 30 14:11:05 1999
From: tpassin at idsonline.com (Thomas B. Passin)
Date: Mon Jun  7 17:18:03 2004
Subject: Web Architecture
References: <Pine.LNX.4.10.9911290301370.2504-100000@cauchy.clarkevans.com> <005401bf3aeb$b0e22740$29fbb1cd@tomshp>
Message-ID: <006901bf3b3d$55ee7d00$92fbb1cd@tomshp>

Thinking about SML and small platforms to run it on, it occurred to me that
FORTH would be an interesting language for a simplified SML parser,
especially a SAX-like one.  Has anyone heard of any work on a FORTH XML
processor?

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 14:35:16 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun  7 17:18:03 2004
Subject: A call for reason
Message-ID: <199911301430.OAA20518@nag.co.uk>



> Net result is that SML data will be well-formed but invalid
> name error will not be reported.  Is this too much to ask?

Having SML being well formed but not valid XML is not too much to ask,
but...

The name rules are part of the well formed productions, they are not a
validation constraint.

So as it stands, there will exist valid SML documents that are not well
formed XML and will therefore trigger a fatal error if given to an XML
parser.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 30 14:50:17 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML] Without attrs, you don't need empty elements...
Message-ID: <199911300949910.SM01048@Unknown.>

> Maybe I'm just slow on the uptake, but I suddenly realized that if SML
> omits attributes, there's not likely to be a need for empty elements.
> 
> (Scan your favorite XML sources and see how often there are empty elements
> with *no* attributes.)

With XHTML, you've got a few - BR and HR spring to mind.  Both can have attributes, 
but neither must.
 
While I'm thinking about it, it seems to me that the SML proposal's aim has been shifted 
dramatically, and nobody really seems to have noticed.  The original argument was that 
XML is too massive and too complex a specification, so we needed something smaller 
that people could pick up on more quickly.  (IIRC, an analogy was drawn between how 
people have learned HTML by skimming source code vs. how hard XML supposedly is 
to learn by the same method; SML was to hit closer to the HTML learning curve.)  
Granted, I think this "mini-XML" is better handled by splitting the docs into Basic, 
Intermediate, and Advanced concepts instead of writing new software, but I still see the 
appeal.  XML is a lot to tackle all at once, so simplify it a bit to let people pick it up more 
easily - fine.

All of a sudden, we're forgetting the *people* altogether and trying to see how simple we 
can make the *parser* - "do we really *need* to support Unicode, do we need to 
support decimal *and* hex, and how about throwing elements out the window while 
we're at it?"  Doesn't this miss the whole point of simplifying the language so newbies 
can climb on board easier?  I don't mind if the aim has been changed, but I don't think it 
should be changed without some sort of announcement to that effect.

If you want something that people can learn easily, the current branches of the SML 
discussion are *FAR* off-target.  If you want a parser that'll fit in a keychain, you'll have 
to ditch the concept of easy buy-in for Joe Average.  All I'm sayin' is, pick a story and 
stick to it.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 15:05:38 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun  7 17:18:03 2004
Subject: [SML]
Message-ID: <199911301501.PAA20584@nag.co.uk>


> I do not think it is superflous to allow &#xA4;.

Given that this is defined to be the same as $ at the lowest level of xml
parsing, I can not see any reason why the arguments currently being
applied to get rid of attributes (which are nowhere nearly as closely
identified with the `equivalent' element markup) do not apply to this
case as well.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 30 15:05:49 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:18:04 2004
Subject: [SML] Without attrs, you don't need empty elements...
Message-ID: <199911301005378.SM01048@Unknown.>

Excuse me, I mistyped:

> All of a sudden, we're forgetting the *people* altogether and trying to see how simple
> we can make the *parser* - "do we really *need* to support Unicode, do we need to 
> support decimal *and* hex, and how about throwing elements out the window while 
> we're at it?"  Doesn't this miss the whole point of simplifying the language so newbies 
> can climb on board easier?  I don't mind if the aim has been changed, but I don't think
> it should be changed without some sort of announcement to that effect.

Naturally, that "throwing elements out" should read "throwing *attributes* out".  Mea 
culpa.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From jlapp at webMethods.com  Tue Nov 30 15:08:57 1999
From: jlapp at webMethods.com (Joe Lapp)
Date: Mon Jun  7 17:18:04 2004
Subject: SML - a vote against
Message-ID: <3.0.32.19991130100957.01cb0330@nexus.webmethods.com>

I've decided that I'm also against SML, as it has been unfolding.  Len
Bullard's email (which did not seem to make it into the archive) was the
turning point for me.  We are on the wrong track.  We should not be trying
to re-invent anything.

Instead, what I'd like to see is the codification of subsets and
recommendations for domains of use of these subsets.  For example, in the
domain of XML for business messaging, if not for all of XML-for-data, I'd
like to see a formal recommendation to avoid both entity declarations and
mixed content.  I'd like to make it easy for someone who knows their domain
of use to identify exactly what they need to learn about XML and to learn
just those pieces.  Applications could advertise conformance with various
recommendations to ease both learning to use the application and
integrating with the application.

Perhaps other problem areas could have their own subset recommendations.
What might be an appropriate approach to making this happen?  Is there
interest to do this in other areas where XML is applicable?

At 01:57 PM 11/30/99 +0000, John Aldridge wrote:
>Here's my take on the SML debate...
>
>XML has been designed to be flexible enough to cover a wide range of
>application domains, and to be broadly compatible with some existing
>practice in this arena.  In reaching this design, compromises had to be
>reached between simplicity and this flexibility and compatibility.
>
>We probably all have quibbles about the wisdom of some of the compromises
>reached; but on the whole, I suggest that a good balance has been reached
>between addressing the needs of a broad range of applications, and keeping
>the standard simple enough to be managable.
>
>There will certainly be many applications for which this full flexibility
>is not required; and similarly many applications where compatibility is not
>an issue.  The question is whether, for these applications, the penalties
>of using XML as it stands are large enough to warrant not using it.
>
>The benefit of a single standard is that we will all profit from a rapid
>proliferation and deployment of tools which operate on information
>conforming to this standard.  Every division in the standard dilutes this
>benefit.
>
>The disadvantage is that applications have to carry the implementation
>costs of features which they do not use.
>
>In the end, I think this is a case where be benefits of a single standard
>comfortably outweigh the costs.  Let's stick with the one we've got.
>-- 
>Cheers,
>John
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>
--
Joe Lapp                     (Looking for some good people to
Senior Engineer               help create XML technologies that
http://www.webMethods.com     connect businesses to businesses
jlapp@webMethods.com          over the web.)

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



From Dimitris.Dimitriadis at linq.com  Tue Nov 30 15:29:05 1999
From: Dimitris.Dimitriadis at linq.com (Dimitris Dimitriadis)
Date: Mon Jun  7 17:18:04 2004
Subject: A call for reason, another go [SML et al]
Message-ID: <65C559669D59D211B5320008C7B987395C5A91@ORION>

I've been following this discussion, and have a few, non-technical points to
make (being a philosopher of language/logician I do not qualify for making
technical claims).

The analogy one could have in mind in trying to decide whether or not to
follow the SML-line is quite simple:

Given that the important question is whether, and if so, to what degree, XML
can model complex information structures successfully (and if SML, a simpler
version of XML could do the same job without added complexity), one need
only bear in mind that those kind of structures seem to be able to convey
meaning when uttered in natural language and heard by a human being. This
same level of semantics would be achieved if:

(i) XML (or any other markup language) had semantics --in and of itself--
which it of course does not (and this is the key to the entire
problem),therefore we have to opt for going for the least incompete *ML
(substitute * for a letter of your liking), and

(ii) Whether this more or less incomplete *ML can be maximized in order to
get as much structure as possible out of it. Given that no *ML is "complete"
in the sense mentioned above, we should opt for a high ration of
complexity/expressibility

If these two are accepted, and the claims made in (ii) are indeed worth of
pursuing, I see no point in taking one, fairly standardized *ML, namely XML,
and simplifying it to the degree where the cost of losing expressibility
clearly overweighs the gains concerning complexity by switching to a simpler
*ML, namely SML.

I hope I have made my point clear. I'd be glad to receive feedback.

Kind regards,

D. Dimitriadis

-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@idsonline.com]
Sent: Tuesday, November 30, 1999 2:38 PM
To: xml-dev@ic.ac.uk
Subject: Re: A call for reason


Don Park wrote:
> ...
> Lately, I have been trying to gain a different perspective
> by thinking what if SML was here first and XML was actually
> SML 2.0?  This line of thinking adds a rather interesting
> appreciation of attributes.
> ...
> Don Park

I'm starting to like Don's thinking here.  What a neat idea!  But there is
one thing against the notion, which probably is responsible for  a lot of
the desire for an SML.  XML has got some historical baggage.  If it were
really SML 2.0, SML 1.0 would have had the same baggage.  But it seems that
the baggage is what people want to eliminate.

Entities are an example.  You could replace &lt;, &amp;, and the rest with
some escape mechanism (like the backslash, I don't mean CDATA), and get rid
of all other entity types.  That would probably simplify things.  But then
you aren't a subset of XML anymore.  On the other hand, if you omit DTDs,
you could still be a subset.  I don't sense a consensus on the importance of
being a subset of XML, but I don't think things can really go anywhere until
this is pretty well settled (to first order, anyway).  Look at the number of
arguments about attributes that are being posted.  The people who actually
write parsers have been saying that there is virtually no cost in memory or
complexity to having attributes.  There's obviously a lot of people who find
them useful.  I think that anyone who sees an attribute in HTML for the
first time understands how to use them and their syntax.  It doesn't confuse
anything to have attributes. So leave them in and move on!

Regards,

Tom Passin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 15:24:06 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:04 2004
Subject: A call for reason
In-Reply-To: <199911301430.OAA20518@nag.co.uk>
Message-ID: <000301bf3b47$400d6640$099918d1@docuverse1>

>So as it stands, there will exist valid SML documents that are not well
>formed XML and will therefore trigger a fatal error if given to an XML
>parser.

I was talking about removing an error reporting requirement
because I believe XML WG went overboard with the error
reporting requirements which places a heavy burden on
the performance of XML parsers.

IMHO, HTML crowd got burnt badly with HTML's forgivable parsers
and over-reacted.  There are other ways to solve this sort of
problems without resorting to high tariff on all.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 15:30:04 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun  7 17:18:04 2004
Subject: What's the current status of SAX2?
In-Reply-To: <27CD34D68C7DD211A68A0004AC38272A023ED43E@elizabeth.int.westgroup.com>
References: <27CD34D68C7DD211A68A0004AC38272A023ED43E@elizabeth.int.westgroup.com>
Message-ID: <14403.60666.152751.179832@localhost.localdomain>

Duffy, Bruce writes:

 > What's the status of SAX2?  The most recent posting I've
 > seen on xml-dev was in June.  Is SAX2 still alive?

Well, it is, but it's on life-support.  I'm finding it very hard to
make time for SAX2 and other related projects.


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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 16:09:49 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:04 2004
Subject: [SML] Without attrs, you don't need empty elements...
In-Reply-To: <199911300949910.SM01048@Unknown.>
Message-ID: <000501bf3b4d$a812fb00$099918d1@docuverse1>

>All of a sudden, we're forgetting the *people* altogether and 
>trying to see how simple we can make the *parser*
[snip]

Reverand,

By the tone of your message, I get the sense that you
assume 'we' collectively forgot what 'we' said before
and are inconsistent or diverted.

This is not true.  Just as you are interested in 'easy
to learn' aspect of SML, each of us come to SML with
different needs.  I am interested in finding the right
balance which could mean that no one will be completely
satisfied nor deprieved.

If current SML threads are far-off target as you say,
it is because not everything can be discussed at once.
Also, you should bring up the issue of "easy to learn"
whenever it seems relevent in any of the threads.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 16:09:38 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:04 2004
Subject: [SML]
In-Reply-To: <199911301501.PAA20584@nag.co.uk>
Message-ID: <000401bf3b4d$a6462a40$099918d1@docuverse1>

David,

>> I do not think it is superflous to allow &#xA4;.
>
>Given that this is defined to be the same as $ at the lowest 
>level of xml
>parsing, I can not see any reason why the arguments currently being
>applied to get rid of attributes (which are nowhere nearly as closely
>identified with the `equivalent' element markup) do not apply to this
>case as well.

Not allowing &#xA4; means:

1. SML parsers will have to check for it which
   complicates implementation.

2. SML spec will have to explain it which
   complicates the spec.

For above two reasons, I do think &#xA4; should
be allowed.

Does this answer your question?

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 16:39:08 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:18:04 2004
Subject: unsubscribe
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90C7@sohos002.ied-support.net>

Nice symmetry.


> -----Original Message-----
> From: Manoranjan Dash [mailto:mdash@techbooks.com]
> Sent: Tuesday, November 30, 1999 5:26 AM
> To: Rashmi Joshi
> Cc: xml-dev@ic.ac.uk
> Subject: Re: unsubscribe
> 
> 
> Unsubscribe
> 
> 
> 
> 
> At 08:15 AM 11/29/1999 -0800, Rashmi Joshi wrote:
> >Unsubscribe
> >
> >
> >xml-dev: A list for W3C XML Developers. To post, 
mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From ksievers at novell.com  Tue Nov 30 17:09:51 1999
From: ksievers at novell.com (Kent Sievers)
Date: Mon Jun  7 17:18:04 2004
Subject: [SML]My opinion - SML in general
Message-ID: <s843a232.087@orm-mail20.orem.novell.com>

I am not interested in changing parsers or creating a competing standard.  If SML is not a strict subset of XML then I am simply not interested.  My definition of a subset would fall in line with "defining an XML language which chooses not to use <insert feature list here>".  

I would like to see where the SML simplification takes us, at least as an exercise, because I am very concerned about the complexity of each new recommendation that is comming out and trying to build upon previous recommendations.  I am also convinced that the dropping of some of the things that have been suggested could significantly simplify DOM, namespaces, XSL, queries, schemas, pointers, etc.  

This is not because I am interested in palmtops, speed or size; but because I am interested in the interoperability of the recommendations and the slow pace at which they proceed.  I am convinced that the extra bagage of the entire XML feature set is at the heart of the problem.

I am also disapointed with the open debate here.  Can't a few good people sit down and work on this.  I don't think the the benefits of SML will be appearent until people can see how (or if) it simplifies subsequent  recommendations.  It will also continue to sound like "taking a step backwards" until the SML design catches up with current XML and people can debate a current topic like schemas.  I think there would be a lot of interest if it made schemas a lot simpler.  Until then, I am inclined to "tune -out" this debate.

Finally, until at least some preliminary work is done on DOM, Namespaces, XSL, queries, etc. it will be hard to know what features were really not worth their cost.  For example, I suspect (but I don't know for sure) that "simplifying the character set" will do nothing to simplify anything but parsers (in which case I am not interested), while the savings for choosing not to use attributes may be enourmous (admittedly guessing).


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



From vlashua at RSGsystems.com  Tue Nov 30 17:20:35 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:18:04 2004
Subject: A call for reason, another go [SML et al]
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9D58@MAILPROD>

In other words, SML may fill a very narrow niche that is probably better
served by paying a small penalty in complexity and size. Is SML a
three-week-old spam? Don Park: publish a document and ask for comments; or,
start the sml-dev list and see who comes; or, don't mention it for a couple
of weeks and see if it rears its head again on its own. Meanwhile, I'd like
to propose a much simplified version of XML called Virtual ML ...
Vane

-----Original Message-----
From: Dimitris Dimitriadis [mailto:Dimitris.Dimitriadis@linq.com]
Sent: Tuesday, November 30, 1999 10:27 AM
To: xml-dev@ic.ac.uk
Subject: RE: A call for reason, another go [SML et al]


I've been following this discussion, and have a few, non-technical points to
make (being a philosopher of language/logician I do not qualify for making
technical claims).

The analogy one could have in mind in trying to decide whether or not to
follow the SML-line is quite simple:

Given that the important question is whether, and if so, to what degree, XML
can model complex information structures successfully (and if SML, a simpler
version of XML could do the same job without added complexity), one need
only bear in mind that those kind of structures seem to be able to convey
meaning when uttered in natural language and heard by a human being. This
same level of semantics would be achieved if:

(i) XML (or any other markup language) had semantics --in and of itself--
which it of course does not (and this is the key to the entire
problem),therefore we have to opt for going for the least incompete *ML
(substitute * for a letter of your liking), and

(ii) Whether this more or less incomplete *ML can be maximized in order to
get as much structure as possible out of it. Given that no *ML is "complete"
in the sense mentioned above, we should opt for a high ration of
complexity/expressibility

If these two are accepted, and the claims made in (ii) are indeed worth of
pursuing, I see no point in taking one, fairly standardized *ML, namely XML,
and simplifying it to the degree where the cost of losing expressibility
clearly overweighs the gains concerning complexity by switching to a simpler
*ML, namely SML.

I hope I have made my point clear. I'd be glad to receive feedback.

Kind regards,

D. Dimitriadis

-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@idsonline.com]
Sent: Tuesday, November 30, 1999 2:38 PM
To: xml-dev@ic.ac.uk
Subject: Re: A call for reason


Don Park wrote:
> ...
> Lately, I have been trying to gain a different perspective
> by thinking what if SML was here first and XML was actually
> SML 2.0?  This line of thinking adds a rather interesting
> appreciation of attributes.
> ...
> Don Park

I'm starting to like Don's thinking here.  What a neat idea!  But there is
one thing against the notion, which probably is responsible for  a lot of
the desire for an SML.  XML has got some historical baggage.  If it were
really SML 2.0, SML 1.0 would have had the same baggage.  But it seems that
the baggage is what people want to eliminate.

Entities are an example.  You could replace &lt;, &amp;, and the rest with
some escape mechanism (like the backslash, I don't mean CDATA), and get rid
of all other entity types.  That would probably simplify things.  But then
you aren't a subset of XML anymore.  On the other hand, if you omit DTDs,
you could still be a subset.  I don't sense a consensus on the importance of
being a subset of XML, but I don't think things can really go anywhere until
this is pretty well settled (to first order, anyway).  Look at the number of
arguments about attributes that are being posted.  The people who actually
write parsers have been saying that there is virtually no cost in memory or
complexity to having attributes.  There's obviously a lot of people who find
them useful.  I think that anyone who sees an attribute in HTML for the
first time understands how to use them and their syntax.  It doesn't confuse
anything to have attributes. So leave them in and move on!

Regards,

Tom Passin

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



From narasimha.ayyagari at mciworld.com  Tue Nov 30 17:40:10 1999
From: narasimha.ayyagari at mciworld.com (narasimha.ayyagari)
Date: Mon Jun  7 17:18:04 2004
Subject: Unsubscribe
Message-ID: <001001bf3b59$4f559480$e21c143f@narasimha>

Unsubscribe



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



From l-arcini at uniandes.edu.co  Tue Nov 30 17:44:33 1999
From: l-arcini at uniandes.edu.co (Fabio Arciniegas A.)
Date: Mon Jun  7 17:18:04 2004
Subject: [SML][LONG]Why i don't like SML [was: Re: sml without...
In-Reply-To: <000501bf3b4d$a812fb00$099918d1@docuverse1>
Message-ID: <Pine.GSO.3.96.991130123928.27016B-100000@isis>

>.  Just as you are interested in 'easy
> to learn' aspect of SML, each of us come to SML with
> different needs.  I am interested in finding the right
> balance which could mean that no one will be completely
> satisfied nor deprieved.

With all respect, and knowing that this was surely said before: 
1.There are many possible SMLs even for such groups as english-speaking
users of north america... over-simplification of an already reasonable
subset may lead not only to confusion but to a waste of valuable efforts.

2.Wittgenstein said "Let the game show its rules to you"... confusion
about what the game has shown and what we individually want (to strip from
it) is the source of much of the discussion inside SML.
We seem to have mistaken popular conceptions (like the idea of uselesness
of attributes -which i don't share btw-) with many artificial ideas that
are far from being
perceived as a benefit by the majority(e.g.only utf-8)

In short, many things about SML(s) seem to me not a "popular need" but a
collection of 
restrictions which aren't wide enough to be united and promoted as a set.
(...the fact that 
they include some commonly believed restrictions may delude us).

3.All the proposed restrictions are enforceable via other mechanisms(as
they may be needed),
withouth compromising with any extra conventions and keeping compatibility
with XML.

4.The size reduction/speed increase of the parsers is hardly an issue 
(at least for a vast majority).

5.Naturally, all of the above points have been exposed before(luckily more
clearly :) ],
and it seems to me that the answer to them tends to be "there is nothing
wrong with putting a tag
to it and try it... let the butterfly die in the winter if it must"... I
disagree with that answer, the efforts
on the wrong place (not saying SML necesarily is) are never neutral, at
least they are a 
lamentable waste and that is undesirable.

Of course i can tell nobody what to do with their time/effort but it is
clear to me that there are many
still unresolved questions in the higher levels of the XML arena and there
is where our efforts
should be.

Best regards,
		Fabio Arciniegas A.

Fabio




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



From mpogue at apache.org  Tue Nov 30 17:43:33 1999
From: mpogue at apache.org (Mike Pogue)
Date: Mon Jun  7 17:18:04 2004
Subject: XML4J EA2 --> Xerces-J 1.0
Message-ID: <38440B68.886AA1DD@apache.org>

Eric Ulevik wrote:
>From: Mike Pogue <mpogue@apache.org>
>> The Xerces-J parser (the Apache name for what IBM calls XML4J EA2) is
>> both compliant (including passing one test that we disagree with your
>> interpretation of the spec on), and is freely available.  Both source
>> code and binaries for Xerces-J version 1 are available at
>> http://xml.apache.org, with updates done frequently.

>I haven't seen any updates. Just the original release. Am I mistaken?

The *very* latest source (including new functionality, and some late
breaking performance and memory enhancements) is available via anonymous
cvs (see http://xml.apache.org for details).  

We'll be bundling the latest source code up into a more formal release
(zip file, tarball) shortly (it's being tested right now).

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 17:50:29 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun  7 17:18:04 2004
Subject: [SML]
Message-ID: <199911301746.RAA14440@nag.co.uk>


> Not allowing &#xA4; means:
> 
> 1. SML parsers will have to check for it which
>    complicates implementation.
> 
> 2. SML spec will have to explain it which
>    complicates the spec.
> 
> For above two reasons, I do think &#xA4; should
> be allowed.

It seems I could replace " &#xA4;" by "attributes" in the above.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 17:54:40 1999
From: wunder at infoseek.com (Walter Underwood)
Date: Mon Jun  7 17:18:04 2004
Subject: Use cases for XML failure  (was Re: #2 Re: [SML] Whether
  to support Attribute or not?)
In-Reply-To: <000801bf394d$23bb3680$099918d1@docuverse1>
References: <001301bf392e$6ad731f0$fad45dc7@ebt.com>
Message-ID: <3.0.5.32.19991130095217.00bb5bf0@corp.infoseek.com>

At 07:02 PM 11/27/99 -0800, Don Park wrote:
>
>SML is not about doing what XML *cannot*.  SML is about
>creating an ideal tool.

"ideal". For what use? That is why the use cases are important.
Without use cases, "ideal" is meaningless.

Also, highly-optimized solutions tend to be evolutionary dead
ends. I prefer tools that may not be perfect, but are well-defined,
widely-used, flexible, and have room for extension. Like XML.

wunder
--
Walter R. Underwood
Senior Staff Engineer
Infoseek Software
GO Network, part of The Walt Disney Company
wunder@infoseek.com
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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gmessner at vsi.com  Tue Nov 30 18:00:12 1999
From: gmessner at vsi.com (Greg Messner)
Date: Mon Jun  7 17:18:05 2004
Subject: XML-to-Java Tools
Message-ID: <807E1C18A44ED311B72500902746407F07564F@epicenter.vsi.com>

Take a look at:

	http://www.vsi.com/breeze

You'll find info on Breeze Commerce Studio. Breeze is basically an IDE for
XML/Java/SQL development, it imports XML documents, XML DTDs, and JDBC/ODBC
data sources and produces Java code to access XML and databases as true
objects. An advantage Breeze has over the Bean Maker in XPK4J is that you
can assign data types to the XML elements. Breeze is currently free for
non-commercial use.


-----Original Message-----
From: Mark Papiani [mailto:mp@ecs.soton.ac.uk]
Sent: Tuesday, November 30, 1999 1:33 AM
To: xml-dev@ic.ac.uk
Subject: XML-to-Java Tools


I am about to start an evaluation of available tools that can generate
Java classes from XML documents, preferably from XML DTDs. Can anyone
recommend useful tools for this purpose. We wish to make it easy for our
developers to generate/read/maintain XML documents from Java programs,
ideally by using classes and accessor/mutator methods to represent the
XML document.

I believe that XBeans from IBMs XML Productivity Kit for Java  (XPK4J)
accomplishes this, but would welcome any recommendations for other tools
that I should investigate.

Many Thanks,

Mark Papiani
Department of Electronics and Computer Science
University of Southampton
mp@ecs.soton.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From smohr at voicenet.com  Tue Nov 30 18:01:34 1999
From: smohr at voicenet.com (Stephen T. Mohr)
Date: Mon Jun  7 17:18:05 2004
Subject: SML - an alternative
Message-ID: <013601bf3b5c$d5b1e9e0$e9d9f2cc@omicron.com>

I wonder if the markup community is best served by trying to create yet
another standard.  Clearly, this discussion indicates that XML has problems.
I suspect we'd be better off finding the solution -- we'd have a better tool
without diminishing the momentum behind XML.  In that vein, then, some
thoughts.

People who have built parsers claim the alleged complexity of XML isn't a
problem for them *as XML stands*.  Not having built one of my own, I'll take
their word for it.

As a writer, I'd agree there is a real documentation problem with the
recommendations.  People like me need to explain the Recs to programmers,
but how about better examples in the Recs?  They're kind of thin.  For that
matter, there is an appalling lack of internal consistency in some of the
drafts I've seen.  As a community, we need to find a way to bring newcomers
up to speed without telling them they are incompetent if they don't know the
intricacies of entities, say, on day one.  Coming from the XML-as-data camp,
I seldom have need for them.  The XML-as-publishing people do.  Let's
recognize that different communities exist which require different tool
sets.

As a programmer, I am concerned with the spiraling growth of standards and
apps that build on "core" XML, e.g., XSLT, XPointer, etc.  This is where I
think this list could help.  The same impulses that are driving the SML
discussion should drive us to discuss what the minimal set of standards
should be for a parser.  That is, if you recognize "<?xml version="x.x"?>",
what should you support?  XML 1.0 clearly.  I feel namespaces should be
folded into an update of the XML rec in preference to its orphan status.
The same goes, eventually, for XML Schemas.  But XPath?  XLink?  I think we
could help the community by discussing different levels of processor support
and lobbying W3C for a mechanism for communicating this in documents.  Maybe
a well-known PI or an attribute of the XML declaration.  A processor
encountering a document that requires something beyond the core could
dynamically load a component that supplied that support or reject the
document.  Perhaps there should be a WG on showing how the XML-related
efforts relate, *especially programmatically.*

In summary, then, I think SML is a bad idea being discussed for the right
reasons.  I don't think XML is so badly broken that we need yet another ML
recommendation.  Addressing the problems will require a variety of
approaches.  Let's get at it.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 18:08:17 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:05 2004
Subject: ANN: SML-DEV
Message-ID: <000101bf3b5e$3c718360$099918d1@docuverse1>

I have created SML-DEV mailing list sometime ago as a place
for those interested in SML to continue work on SML.  I did
not announce it before because I felt it wasn't time yet.

I think the time has come.

The mailing list is hosted by eGroups.com.  You can join by
sending a message to:

   sml-dev-subscribe@eGroups.com

The SML-DEV archive, calendar, chat, poll, and other goodies
can be found at:

   http://www.egroups.com/group/sml-dev/info.html

I hope to see you all there to continue on our effort.

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 30 18:16:55 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:18:05 2004
Subject: A call for reason
Message-ID: <199911301135608.SM01048@Unknown.>

> >So as it stands, there will exist valid SML documents that are not well
> >formed XML and will therefore trigger a fatal error if given to an XML
> >parser.
> 
> I was talking about removing an error reporting requirement
> because I believe XML WG went overboard with the error
> reporting requirements which places a heavy burden on
> the performance of XML parsers.

In other words, the WG went overboard in specifying that when something is broken, 
the parser must say so?  I don't consider that overboard at all.

> IMHO, HTML crowd got burnt badly with HTML's forgivable parsers
> and over-reacted.  There are other ways to solve this sort of
> problems without resorting to high tariff on all.

I think the UA authors finally got sick of having to code bloated "forgiving" parsers 
because the HTML spec required a huge amount of tolerance, but I could be wrong.  
After all, this is touchy-feely 1999, where getting the right answer to 1+1 is not as 
important as how you FEEL about the answer you got.  Am I the only programmer left 
who *likes* getting syntax errors that stop your production cold, because they give you 
an error you can fix quickly instead of a problem you may not even notice until it's too 
late?

Way back in the Dark Ages of my computer education, my first real computer science 
teacher told me something very valuable.  There are three sorts of errors in 
programming, each more serious than the last.  The first is a syntax error, and I love 
getting those - because they tell you exactly where the problem is and what's wrong.  
The compiler is supposed to halt compilation on those, because the output is going to be 
garbage anyway.  ("It's broke, so get it fixed.")  The second type is a run-time error - all 
the syntax looks right, but something critical breaks when the program runs.  (See GPF, 
memory allocation errors, etc.)  Here again, you get an error message, so you at least 
know what the problem is.  If you're lucky (or thought ahead), you even get some 
information that helps you track it down.  The third and most serious error is the logic 
error - where the program runs smoothly, but the results are incorrect.  (For instance, 
running a photo of a tree through a rendering system and getting an antelope.)  The 
syntax is right, the resources are cool, but your algorithm is screwed up...and *that's* 
what you have to figure out on your own.

These stringent error-reporting requirements that you complain about are syntax errors, 
sometimes run-time errors - and the WG is quite correct in requiring the parser to kick 
nonconforming documents out instead of trying to figure out what they meant to say.  If 
it's broken at that basic a level, it doesn't need to be set loose - make the author fix the 
errors first.  (And if it's program-generated code, that's an even better reason for this 
requirement - the error will show up in a log, and that lets the software author know 
there's a problem.)

Syntax errors are easy to fix if reported, but they can be damned near impossible to find 
with a mushy parser that lets 'em slide through.  All a tolerant parser does is consume 
CPU cycles and encourage sloppy coding - and neither of those does anybody any good.  
(Well, okay, maybe Intel and AMD benefit...but that's about all.)  The way to fix sloppy 
code is not to tolerate it.  Sure, utilities like HTML Tidy which will fix existing 
documents are nice - but odds are, without a strong push towards intolerance, it never 
would have attained its current level of prominence.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From Karthik at india.adventnet.com  Tue Nov 30 18:17:07 1999
From: Karthik at india.adventnet.com (Karthik)
Date: Mon Jun  7 17:18:05 2004
Subject: unsubscribe
Message-ID: <3844167A.E9E7BB97@india.AdventNet.com>

unsubscribe


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 18:29:23 1999
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun  7 17:18:05 2004
Subject: ANN: SML-DEV
References: <000101bf3b5e$3c718360$099918d1@docuverse1>
Message-ID: <384417CE.FF05059F@finetuning.com>

Thank you!  Oh thank you!  for (hopefully) booting all of this SML
discussion to its own list....

enough is enough...

now let's get back to REAL XML!  :-)

lisa

Don Park wrote:
> 
> I have created SML-DEV mailing list sometime ago as a place
> for those interested in SML to continue work on SML.  I did
> not announce it before because I felt it wasn't time yet.
> 
> I think the time has come.
> 
> The mailing list is hosted by eGroups.com.  You can join by
> sending a message to:
> 
>    sml-dev-subscribe@eGroups.com
> 
> The SML-DEV archive, calendar, chat, poll, and other goodies
> can be found at:
> 
>    http://www.egroups.com/group/sml-dev/info.html
> 
> I hope to see you all there to continue on our effort.
> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 18:38:10 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun  7 17:18:05 2004
Subject: XML Database: position papers ?
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F27818C@MDYNYCMSX1>

>I am looking for some position papers that are doing a comparison of both 
>relational model and object oriented approaches for XML database
conception.

Ronald Bourret's "XML and Databases" at
http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/XMLAndDatabases
.htm doesn't address the issue too directly but will give you some good
background on a lot of related issues.

Bob DuCharme       www.snee.com/bob       <bob@  
snee.com>  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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From smuench at us.oracle.com  Tue Nov 30 18:38:50 1999
From: smuench at us.oracle.com (Steve Muench)
Date: Mon Jun  7 17:18:05 2004
Subject: XML-to-Java Tools
References: <807E1C18A44ED311B72500902746407F07564F@epicenter.vsi.com>
Message-ID: <007301bf3b51$535a9ba0$5a672382@us.oracle.com>

Oracle's XML Class Generator for Java & C++
are others to consider. It's part of our XML Developer's
Kit that is available with a redistributable license
and full support.

http://technet.oracle.com/tech/xml


_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: Greg Messner <gmessner@vsi.com>
To: 'Mark Papiani' <mp@ecs.soton.ac.uk>; <xml-dev@ic.ac.uk>
Sent: Tuesday, November 30, 1999 11:56 AM
Subject: RE: XML-to-Java Tools


| Take a look at:
|
| http://www.vsi.com/breeze
|
| You'll find info on Breeze Commerce Studio. Breeze is basically an IDE for
| XML/Java/SQL development, it imports XML documents, XML DTDs, and
JDBC/ODBC
| data sources and produces Java code to access XML and databases as true
| objects. An advantage Breeze has over the Bean Maker in XPK4J is that you
| can assign data types to the XML elements. Breeze is currently free for
| non-commercial use.
|
|
| -----Original Message-----
| From: Mark Papiani [mailto:mp@ecs.soton.ac.uk]
| Sent: Tuesday, November 30, 1999 1:33 AM
| To: xml-dev@ic.ac.uk
| Subject: XML-to-Java Tools
|
|
| I am about to start an evaluation of available tools that can generate
| Java classes from XML documents, preferably from XML DTDs. Can anyone
| recommend useful tools for this purpose. We wish to make it easy for our
| developers to generate/read/maintain XML documents from Java programs,
| ideally by using classes and accessor/mutator methods to represent the
| XML document.
|
| I believe that XBeans from IBMs XML Productivity Kit for Java  (XPK4J)
| accomplishes this, but would welcome any recommendations for other tools
| that I should investigate.
|
| Many Thanks,
|
| Mark Papiani
| Department of Electronics and Computer Science
| University of Southampton
| mp@ecs.soton.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
| unsubscribe xml-dev
| To subscribe 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From rev-bob at gotc.com  Tue Nov 30 18:41:38 1999
From: rev-bob at gotc.com (rev-bob@gotc.com)
Date: Mon Jun  7 17:18:05 2004
Subject: SML and false simplicity
Message-ID: <199911301216654.SM01048@Unknown.>

> >All of a sudden, we're forgetting the *people* altogether and 
> >trying to see how simple we can make the *parser*
> 
> Reverand,

Please, just "Bob" works fine.  I go with the informal version for a reason....
 
> By the tone of your message, I get the sense that you
> assume 'we' collectively forgot what 'we' said before
> and are inconsistent or diverted.

Very good; that is exactly what I meant to say.

> This is not true.  Just as you are interested in 'easy
> to learn' aspect of SML, each of us come to SML with
> different needs.  I am interested in finding the right
> balance which could mean that no one will be completely
> satisfied nor deprieved.

Are you?  Some of the current concepts are *way* out in left field from the original 
"make XML easier to learn" proposal.  "Scrap DTDs because they're hard" is a long way 
from "get rid of attributes because we can use elements instead" and "get rid of decimal 
entities because we can get by with hex".  Here's a tip - keeping attributes is important 
because it draws an intuitive parallel with HTML, and that in turn makes the new 
language easier to learn via analogy.  Allowing hex and decimal entity values is important 
because Joe Newbie doesn't have to unlearn and relearn (or go through and convert) the 
values he already knows.

In terms of document syntax, I have to say that I find XML significantly simpler than 
HTML.  Instead of having to puzzle out whether <X> is an empty element or an opening 
container tag that will have a matching </X> down the line, I can just look at it and know 
- no slash, so it opens a container.  Simple, honest, cut-and-dried.  Instead of trying to 
figure out where an element ends by tracking down start tags that will imply an end tag 
where none exists, I look for the required end tag.  Why complicate things by trying to 
oversimplify the parser into something that requires nightmarishly complex 
documents...which are therefore orders of magnitude harder to "read and imitate"?  
About the only thing that confuses me on XML right now is making a DTD, and that 
primarily because still I'm trying to figure out how you tell a UA what it should do to 
render a given tag without putting it in terms of HTML.  ("Okay, I want this form 
element to display like a checkbox - how do I do that?")  As far as the actual semantic 
construction goes - well, it'd be a lot of work, but *hard*?  I ain't so sure.

I'm still of the opinion that the original "make XML easier to climb onto" goal is best 
addressed by putting training wheels on the *docs*, not on the *language*.  Take 
JavaScript, for instance.  JavaScript is a rather complex language if you get into all the 
depths of all the different editions - try to tackle it all at once, and you'll probably run 
screaming from the room.  On the other hand, if you swipe a couple of routines from 
existing web pages and examine them to see how they work, you can leverage your way 
up into a basic understanding of the language.  Once you get that down, you move into 
more advanced areas - and then, should you decide to venture further, you can explore 
the truly arcane realms.  Nobody says you have to learn it all at once...just like nobody 
says you have to learn XML all at once.  The question of learning JavaScript is not 
solved by dumbing down JavaScript, but in writing better documentation for the language 
as it exists, and that's been done a few times.  Why not try the same thing with XML, 
instead of splitting the spec and eventually confusing users all the more?

To put it bluntly - if the problem is the learning curve, fix the docs instead of rewriting 
the language.  Why reinvent the wheel when a perfectly good one already exists?

> If current SML threads are far-off target as you say,
> it is because not everything can be discussed at once.

That excuse only goes so far.  Some of the "simplification" ideas out there are downright 
arcane when it comes to usability - and the rationale behind these has been "we'll fix it in 
the API" and similar statements.  (Case in point - decimal entities; I was told specifically 
that the tools should handle the conversion, so the parser wouldn't have to.)  This is 
backwards; you have lost sight of your goal, and I'm calling you on it.  I don't care how 
slick the parser is; Joe Newbie is not going to be happy about trying to figure out:

<p><text>This is a paragraph with some</text><b>bold</b><text>text inside it that 
is</text><em>unneccessarily</em><text>separated from its context.</text></p>

That may be simple for the parser to handle, and the vaporware tools may make it easy 
to create the document, but the stated goal was "easy to learn," especially by example - 
and that example is anything but easy to learn from, unless the desired lesson is "go back 
to HTML."  (I was going to add a few stylistic directives and object handles - like an ID 
- in there, but I couldn't figure out *how*; what does that tell you about the simplicity of 
your new dialect?  Sure, maybe you *can* code without attributes - but only at the cost 
of a deeper and more error-prone element tree.)

> Also, you should bring up the issue of "easy to learn"
> whenever it seems relevent in any of the threads.

And I'm doing so right now - in a new thread, because the issue is global to all the 
existing SML threads.  Consider the gauntlet thrown; I hereby declare that the syntax-
minimization efforts under discussion are not merely irrelevant to the "easy to learn" 
goal, but rather they are *counterproductive* to that effort.  If anyone cares to 
demonstrate that I am wrong, have at it.  If this effort is truly on the Fast Track to 
Standard, this should be no problem at all.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 18:48:56 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun  7 17:18:05 2004
Subject: A call for reason, another go [SML et al]
In-Reply-To: <A51F7543E295D2118D6600A024CDB2F71B9D58@MAILPROD>
Message-ID: <000201bf3b63$e9856da0$099918d1@docuverse1>

>In other words, SML may fill a very narrow niche that is 
>probably better served by paying a small penalty in
>complexity and size. Is SML a three-week-old spam?

Vane,

There is no need to resort to vanity, Vane.  For
what purpose would I spam XML-DEV?  All the discussions
that took place were valuable in that they allowed us
to examine many aspects of XML which were taken for
granted before.  I wrote sometime ago in a message
titled "Feeling good about SML":

"Whether SML is the voice of reason or treason, it struck
a cord in the mind of many of us.  Whether the need for SML
is illusional or practical, it merits further investigations
and thus require investment in terms of time and efforts.  By
time and effort, I include the patience and continued vigilence
of those XML-DEV subscribers who disagree with the SML idea."

Frankly, I am somewhat dismayed by the lack of vision and
paranoia over the supposedly endangered future of XML.  Has
it ever occurred to anyone that messages asking me and others
to stop working on SML is just plain weird?  Is XML-DEV turning
into a political organization in charge of protecting XML from
mutants and anything that dares to use angled brackets?  I am
rather alarmed by all this.  Is XML so vulnerable that even all
the media hype over XML is still not enough?  Where is Darwin
in all this?

Everyone assumes that homes in the future will be fully
automated but how will all the electronic gadgets talk to
each other?  Will the porch light scream at the doormat because
it sent invalid tag names?  "Sorry, the guy's shoes stutters!"

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 19:00:49 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun  7 17:18:05 2004
Subject: Web Architecture
Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E90C9@sohos002.ied-support.net>

Robert La Quey wrote:
> Yes, nice point, so we might say:
> 
> SGML:XML:SML <=> Ptolemy:Copernicus:Kepler

Next you'll be saying that Don is Martin Luther King. (Don King?)

> ><sorry reason="off topic"/>
> 
> No reason to be sorry. Not really off topic. Thanks for 
> improving on the 
> original statement. Historical understanding of the great 
> shifts in paradigms 
> is the most pragmatic of understandings. Even the Cowardly 
> Lion knows that. 

Is this to say that SML is a paradigm shift? A somewhat self-deluding
proposition if so.

I can see that this SML stuff is unstoppable, and before I unsubscribe
from this 'SML mailing list', I would like to make a couple of simple
points:

1. SML is not contributing anything to the greater understanding of
mark-up languages.
   Witness the fact that the debates are re-hashes of old XML debates,
not new ones.

2. If you want to simplify XML for beginners then go ahead. But why not
just write the
   definitive introductory book that takes the core features and
explains them so simply
   that it just seems obvious, and then has an appendix called 'other
features of XML
   you might want to use but don't worry about for now'.

3. Otherwise a newcomer can legitimately say, should I use SML or XML?
This is not the
   same as the choice between XML and SGML, for well known reasons, but
has now sowed
   confusion where SML's proponents claimed to clarify.

4. The size question is a non-issue. Don made preposterous claims about
doubling the speed
   of parsing and halving the size of the parser. Some of the people who
have actually
   written the current crop of XML parsers have said this is 'unlikely'.
Don offers no
   proof - just "a guess". With such scientific rigour it is a surprise
that we are even
   aware of planets, never mind their elliptical orbits.

I have to apologise to those who will now be offended, but much of this
smacks of playing at grown-ups. When a child stands in the shoes of
their parents it is amusing. But when people cut and paste the hard work
and insight that made up the evolution from SGML to XML, passing it off
as their own, it is not a pleasant sight. Sending EBNFs backwards and
forwards - for what? Large shoes - small feet.

The very notion of SML shows a lack of understanding of how XML came
from SGML; the congruity of developments in data, mark-up and in
particular a historically unprecedented desire for standards.

Anyway, I'm not too sad. I remember the day I stumbled on this list;
reading people's ideas and following their arguments, and then
contributing my own. I remember my brain buzzing for days on end with
new ideas for applications and what the internet might eventually become
- stimulated by thoughts and debates from this list. I have learned a
lot from the wise contributions of some genuinely talented people, and
thank them for it.

Where to now? Well, I'm off to the lists where they're doing something.
A common theme in the SML discussion is the supposed 'proliferation' of
standards and the difficulty in keeping up with them. Well, SML won't
help I'm afraid. But here - if anyone is interested - is my pick of the
specs. They're where I'll be hanging out from now on:

RDF
I recommend to those of you who haven't, to really try to get to grips
with RDF. I had to read the spec a number of times before its real
significance came through, and now I am enthusing about RDF like I was a
year or so ago with XML. Hopefully the rest of you won't be as dim as me
and will get it much faster; but if you are, the extra effort is still
worth it.

SOAP/XML-RPC
Also, have some fun with SOAP and XML-RPC. Controlling one server from
another is an important part of the future.

WebDAV
More substantial though, for real industrial-strength systems, is
WebDAV. Particularly important for group working - although don't treat
that notion too narrowly. Most current systems use it for file control
but it's very exciting for providing a standard way of manipulating
databases or other dynamic content.

DASL
What about index servers that index other indexes? Got to be an
important part of the future, and DASL looks at ways to search this meta
information.

WAP
Sure, I know they shouldn't have done it, but they have. WAP will
probably have a few years life before everything harmonises (around XML
2.0?), but in the meantime who can honestly say they don't want to allow
access to their corporate intranet through a phone? Got to be the fun
project that you will try and find a reason for doing next year.

As you can tell I'm mostly interested in anything that deals with the
'meta' end. On other stuff, watch out for using the power of the server
to deliver sophisticated content to legacy browsers. Anyone who didn't
take a look at that Mozquiro stuff that popped up the other day ... go!
Now! What are you waiting for? It's a simple idea beautifully executed.

Best regards everyone, and thanks for having me,

Mark


PS If you're ever in the area ... actually on second thoughts ...

PPS Anyone know how you unsubscribe from this list? (Kidding ... I've
got it here somewhere ...)


Mark Birbeck
Managing Director
x-port.net Ltd.
220 Bon March? Centre
241-251 Ferndale Road
London
SW9 8BJ
w: http://www.iedigital.net/
t: +44 (171) 501 9502
e: Mark.Birbeck@iedigital.net

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



From ksievers at novell.com  Tue Nov 30 19:06:26 1999
From: ksievers at novell.com (Kent Sievers)
Date: Mon Jun  7 17:18:06 2004
Subject: [SML]My opinion - Leaving out attributes
Message-ID: <s843bd99.005@orm-mail20.orem.novell.com>

I think that SML should choose to not use attributes.

My initial reaction to the existence of both attributes and elements was that they were redundant: two ways of representing the same thing.  For example, using them to distinguish data from meta data, simply because they both exist, is arbitrary.  Data vs. meta-data could have been represented using elements only.

But they are not identical.   There are differences between the two.  Attributes can not contain sub-attributes, can not occur more than once, and their order does not matter, for example.  People are laying out languages based on these differences.  Their choices are often arbitrary.  My favorite to date went something like this:
we chose to put our data into attributes, (e.g. <Author  FirstName="Joe"/> instead of <Author><FirstName>Joe</FirstName></Author> because we didn't want repeating properties and this way the parser takes care of them for us.

Each subsequent recommendation has magnified the arbitrary choices.  I have seen people, for example, choose attributes over elements because it takes fewer DOM calls to work with them.  DOM and DTDs seem to lean people toward attrbiutes over elements for reasons that seem equally arbitrary to me.

When the Namespaces recommendation came along, I saw people choosing elements over attributes simply because attributes "did not inherit namespaces properly".

XSL (at least the MicroSoft stuff I have dealt with) has holes in the feature set when dealing with elements that make attributes a better choice.

The current query and pointer stuff, if I understand them, makes elements easier to deal with than attributes.

I can't image the pains that the schema group must be going through trying to deal with both and their differences.

Now, having said all of that, I have to admit that there are two attributes that  I currently do use when I am in charge of the language being designed: xmlns and dt.

Finally, how can people like me (who are forced to consume everyone elses languages) deal with people who choose (being completely within their XML rights) to represent something like:
<property tag="First Name" value = "Joe"/> for aribitrary reason like (this one is my all time favorite) "this way we can have spaces and colons in our tag names." 


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



From frichards at poet.com  Tue Nov 30 19:12:25 1999
From: frichards at poet.com (Frank Richards)
Date: Mon Jun  7 17:18:06 2004
Subject: XML Database: position papers ?
References: <A96F4EECC58DF4DC882568390066A0B4.0066A0FF88256839@poet.com>
Message-ID: <007101bf3b66$862d1e30$6313ccd8@poet.com>

> >I am looking for some position papers that are doing a comparison of both
> >relational model and object oriented approaches for XML database
> conception.
>

Poet Software (for whom I peddle content management systems) has a white
paper at
http://www.poet.com/products/oss/white_papers/rel_vs_obj/rel_vs_obj.html
explaining why OODBMS (especially Poet's) are a better fit for XML.

Frank Richards
Poet Software
frichards@poet.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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  Tue Nov 30 19:19:59 1999
From: digitome at iol.ie (Sean McGrath)
Date: Mon Jun  7 17:18:06 2004
Subject: XFM (or something similar)
Message-ID: <3.0.6.32.19991130190503.0091fd30@gpo.iol.ie>

All,

Some time ago, as part of the SML discussions an idea
was mooted that some sort of standard notation describing
how XML parsers differ, would be useful. For want of a better
name it was called XFM - XML Features Manifest. (The obvious
name for us SGML crusty types would be "XML Declaration" but
that name is taken.).

The idea is that parser writers and document creators
would have a notation to use to describe their
tools/documents and thus
	1) improve interoperability
	2) Make it easier to compare/select tools

For example, a non-validating XML parser have an XFM
that specified things like:
	0) DTD Awareness
	1) Expansion of external entites
	2) Enforcement of Unicode name rules
	3) character set support
	yada, yada	


Do xml-dev'ers think XFM is a good idea?

If so, in order not to clutter up this list, send
me the things you would like to see in XFM. I will
pull'em together and report back to XML-DEV with
an ordered list.

If not, lets meet in the bar at XML'99 anyway. Any
excuse will do:-)

Please put "XFM:" in the title of your e-mails.
Thanks.




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



From smohr at voicenet.com  Tue Nov 30 19:35:21 1999
From: smohr at voicenet.com (Stephen T. Mohr)
Date: Mon Jun  7 17:18:06 2004
Subject: XFM (or something similar)
References: <3.0.6.32.19991130190503.0091fd30@gpo.iol.ie>
Message-ID: <019701bf3b69$e4f9e350$e9d9f2cc@omicron.com>

Turn it around -- require a document to specify what capabilities it
requires of a processor beyond the core, e.g., XLink.  XFM might be
interesting to an installer, but how often do you choose a parser?  I'd like
to open a document and find out right away if my tools are sufficient to
consume it.


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



From KenNorth at email.msn.com  Tue Nov 30 19:38:43 1999
From: KenNorth at email.msn.com (KenNorth)
Date: Mon Jun  7 17:18:06 2004
Subject: XML Database: position papers ?
References: <A96F4EECC58DF4DC882568390066A0B4.0066A0FF88256839@poet.com> <007101bf3b66$862d1e30$6313ccd8@poet.com>
Message-ID: <00bb01bf3b6a$d6d1a960$0b00a8c0@grissom>

From: Frank Richards <frichards@poet.com>
>
> Poet Software (for whom I peddle content management systems) has a white
> paper at
> http://www.poet.com/products/oss/white_papers/rel_vs_obj/rel_vs_obj.html
> explaining why OODBMS (especially Poet's) are a better fit for XML.

Do you have a white paper that includes comparisons of OODBMS with
object-relational databases (when discussing object identity, adding new
types, references among objects, and so on)?









xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 19:47:06 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:18:06 2004
Subject: XFM (or something similar)
Message-ID: <3.0.32.19991130114807.01475710@pop.intergate.ca>

At 07:05 PM 11/30/99 +0000, Sean McGrath wrote:

>Do xml-dev'ers think XFM is a good idea?

I think having a way for an instance to promise it references no external 
entities is a no-brainer.  Beyond that, you start getting past the 20/80 
point pretty damn quick.  In particular, experience would suggest that trying 
to fiddle with character sets is more trouble than it's worth.

>If not, lets meet in the bar at XML'99 anyway. 

Now there's a *good* idea. -T.

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



From devarapalli at hotmail.com  Tue Nov 30 20:15:14 1999
From: devarapalli at hotmail.com (Muralidhar Devarapalli)
Date: Mon Jun  7 17:18:06 2004
Subject: XML-to-Java Tools
Message-ID: <19991130201430.62921.qmail@hotmail.com>

Have a look at Bluestone's XML suite.
http://www.bluestone.com/xml/
You can find tools for generating DTDs and java files.
- Murali Devarapalli
>-----Original Message-----
>From: Mark Papiani [mailto:mp@ecs.soton.ac.uk]
>Sent: Tuesday, November 30, 1999 1:33 AM
>To: xml-dev@ic.ac.uk
>Subject: XML-to-Java Tools
>
>
>I am about to start an evaluation of available tools that can generate
>Java classes from XML documents, preferably from XML DTDs. Can anyone
>recommend useful tools for this purpose. We wish to make it easy for our
>developers to generate/read/maintain XML documents from Java programs,
>ideally by using classes and accessor/mutator methods to represent the
>XML document.
>
>I believe that XBeans from IBMs XML Productivity Kit for Java  (XPK4J)
>accomplishes this, but would welcome any recommendations for other tools
>that I should investigate.
>
>Many Thanks,
>
>Mark Papiani
>Department of Electronics and Computer Science
>University of Southampton
>mp@ecs.soton.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following 
>message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From herrypri at kilomegagiga.co.id  Tue Nov 30 20:31:08 1999
From: herrypri at kilomegagiga.co.id (Herry Prihandoko)
Date: Mon Jun  7 17:18:06 2004
Subject: unsubscribe
Message-ID: <NDBBLFPJOMDFIFIGPIDIGEIMCFAA.herrypri@kilomegagiga.co.id>

unsubscribe

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



From jelks at jelks.nu  Tue Nov 30 20:34:56 1999
From: jelks at jelks.nu (Jelks Cabaniss)
Date: Mon Jun  7 17:18:06 2004
Subject: Web Architecture
In-Reply-To: <3.0.6.32.19991129223025.0406c970@mail.dt1.sdca.home.com>
Message-ID: <NBBBICMNIPCICMKJECCBCEMADCAA.jelks@jelks.nu>

Robert La Quey wrote:

> >Judging from some of the posts, maybe their authors think that the  XML WG
> >is like Copernicus and that Don, with SML, is more like Kepler???
>
> Yes, nice point, so we might say:
>
> SGML:XML:SML <=> Ptolemy:Copernicus:Kepler

Except Ptolemy lived in the 2nd century, Copernicus the 16th, and Kepler the
17th.  SGML was formalized in 1986; XML a year and a half ago.  I know we're
living in Internet Time, but isn't this "simplification" movement throwing out
the XML Baby with the bath water a tad premature?

No doubt XML and her siblings *will* be simplified some day.  Maybe they'll even
drop the most confusing of them -- Namespaces -- and replace them with (gasp!)
attributes. ...

/Jelks


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



From dvint at slip.net  Tue Nov 30 21:22:25 1999
From: dvint at slip.net (Dan Vint)
Date: Mon Jun  7 17:18:06 2004
Subject: XFM (or something similar)
In-Reply-To: <019701bf3b69$e4f9e350$e9d9f2cc@omicron.com>
References: <3.0.6.32.19991130190503.0091fd30@gpo.iol.ie>
Message-ID: <4.1.19991130161343.00965100@pop.slip.net>

I like the idea of having it on both ends my self. 

It would be nice to have a clear statement of everything that the tools
support 
 - xslt
 - xpath
 - xls wd 1.2
 - dom level 1
 - xml validator - use class XXX
 - xml nonvalidator use class YYY
 - and on down the line
 - then it would be nice to know what they do extra or in a non-standard way

This is just going to get worst the way the specifications process seems to
be going and it is the marriage between what your document/data requires
and what the tool supports that will make a combination sink or swim.

..dan


At 02:34 PM 11/30/99 -0500, you wrote:
>Turn it around -- require a document to specify what capabilities it
>requires of a processor beyond the core, e.g., XLink.  XFM might be
>interesting to an installer, but how often do you choose a parser?  I'd like
>to open a document and find out right away if my tools are sufficient to
>consume it.
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 
>981-02-3594-1
>To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>


---------------------------------------------------------------------------
Danny Vint                                       http://www.dvint.com
Author: SGML at Work   	http://www.slip.net/~dvint/pubs/sgmlatwork.shtml 
                                                       mailto:dvint@slip.net
    
Calian                                              Voice:804-975-3482
mailto:d.vint@calian.com
Charlottesville, VA Office                http://www.calian.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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



From gtn at ebt.com  Tue Nov 30 21:50:53 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:18:06 2004
Subject: SML - a vote against
In-Reply-To: <3.0.32.19991130100957.01cb0330@nexus.webmethods.com>
Message-ID: <000b01bf3b7c$5e3cf560$2b7370c6@ebt.com>

> Instead, what I'd like to see is the codification of subsets and
> recommendations for domains of use of these subsets.  For
> example, in the domain of XML for business messaging, if not for all of
> XML-for-data, I'd like to see a formal recommendation to avoid both entity
> declarations and mixed content.

This is, again, precisely the thing I was arguing for in a (much)
earlier post. Forget the syntax. Define the application and domain
specific set of features (application conventions), and be done
with it. It's much easier to get people in the same to domain to
agree to the subset than the public in general.

Again, if a product that claims "supports XML-for-data" generates
data that doesn't conform, interoperability *in that domain*
suffers, so that isn't likely to happen. For conforming messages, it
should be impossible to tell whether there is an XML or an
"XML-for-data" parser under the covers. You get the best of both
worlds.

This is very much like the debates we had for I18N in HTML. In the
end, the canonical model is that everything is ISO 10646. In reality,
application/geographic uses constrain content to particular
encodings.






xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to 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 Nov 30 21:57:35 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun  7 17:18:06 2004
Subject: A call for reason
In-Reply-To: <199911301135608.SM01048@Unknown.>
Message-ID: <Pine.GSU.4.10.9911301330070.9255-100000@netcom9.netcom.com>

On 30 Nov 1999 rev-bob@gotc.com wrote:

> > >So as it stands, there will exist valid SML documents that are not well
> > >formed XML and will therefore trigger a fatal error if given to an XML
> > >parser.
> > 
> > I was talking about removing an error reporting requirement
> > because I believe XML WG went overboard with the error
> > reporting requirements which places a heavy burden on
> > the performance of XML parsers.
> 
> In other words, the WG went overboard in specifying that when something is broken, 
> the parser must say so?  I don't consider that overboard at all.
> 
> > IMHO, HTML crowd got burnt badly with HTML's forgivable parsers
> > and over-reacted.  There are other ways to solve this sort of
> > problems without resorting to high tariff on all.
> 
> I think the UA authors finally got sick of having to code bloated "forgiving" parsers 
> because the HTML spec required a huge amount of tolerance, but I could be wrong.  

The problem with HTML was that the spec basically said "you can attempt to
repair errors in an application-defined fashion."  The result was a
shitload of "HTML" that was "designed" with "knowledge" of particular
applications' (undocumented) error-correction behavior; much of that
"HTML" suddenly became unusable when new versions of popular browsers came
out.  Plenty of Web designers were arguing that they were getting paid to
create pages that worked on what the majority of viewers were using, and
they didn't care whether the only reason they "worked" was that the
browsers' error-correction was giving them the results they wanted.  "I'm
too busy making money to make sure all my quoted attribute values have
closing quotes just so Lynx users can read my pages.  They work just fine
in Netscape."  And so they did, until Netscape 1.0 came out.  And so on
(*every* major release of Netscape came with a change in error-recovery
behavior that broke lots of "they worked" documents).

The lesson here is that allowing parsers to implement their own
idiosyncratic error-recovery strategies inevitably leads to the
proliferation of incompatible "slang" versions of the base language, each
of which is understandable to only one parser implementation.  In the case
of HTML, we were dealing with authors who were either ignorant of the
pitfalls of best-case design ("it works for me and works when I demo it to
the boss, so it must be OK") or actively hostile to the philosophy of
robustness ("when you say that's 'incorrect,' that's just *your*
opinion")--the latter was IMHO partially due to an affected
artistic-rebel-poseur attitude that couldn't distinguish between esthetic
judgments, which, contrary to the moaning of some ultra-conservatives,
*cannot* be treated as truth-valued statements, and criteria for
formal-language correctness.

The requirement that an XML processor not allow application-level attempts
at repairing illegal syntax (which does *not*, BTW, demand that any
application make a "terminate" system call to the OS if there's illegal
syntax; it only demands that the application refuse to process the
document in question) may sound harsh, but the alternative is either the
creation of languages whose grammars can only be inferred by
experimentation, or putting precise error-recovery strategies in the spec
itself (which might work for an appllication-specific language where you
know what the semantics are, but hardly for a metalanguage).

Novice programmers (and non-novice script kiddies) like languages that
don't enforce error-checking because, let's face it, error-handling code
is tedious and boring to write.  But there are only three alternatives:
write the error-handling code, sweep errors under the rug (where they
eventually catch fire), or use a system that's guaranteed not to generate
errors.  The latter option assumes that perfection is not only achievable,
but has already been achieved.



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



From gtn at ebt.com  Tue Nov 30 22:08:32 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:18:06 2004
Subject: A call for reason
In-Reply-To: <199911301135608.SM01048@Unknown.>
Message-ID: <000d01bf3b7e$d6994430$2b7370c6@ebt.com>

> These stringent error-reporting requirements that you 
> complain about are syntax errors, sometimes run-time errors
> - and the WG is quite correct in requiring the parser to kick 
> nonconforming documents out instead of trying to figure out 
> what they meant to say.  If it's broken at that basic a level, 
> it doesn't need to be set loose - make the author fix the 
> errors first.

Absolutely in agreement.

FWIW. It was the browser vendors that asked for draconian
error handling... to the surprise of many XML-WG members.


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



From gtn at ebt.com  Tue Nov 30 22:21:36 1999
From: gtn at ebt.com (Gavin Thomas Nicol)
Date: Mon Jun  7 17:18:06 2004
Subject: A call for reason, another go [SML et al]
In-Reply-To: <000201bf3b63$e9856da0$099918d1@docuverse1>
Message-ID: <000e01bf3b80$a88def30$2b7370c6@ebt.com>

> Frankly, I am somewhat dismayed by the lack of vision and
> paranoia over the supposedly endangered future of XML.  Has
> it ever occurred to anyone that messages asking me and others
> to stop working on SML is just plain weird?  Is XML-DEV turning
> into a political organization in charge of protecting XML from
> mutants and anything that dares to use angled brackets?  I am
> rather alarmed by all this.  Is XML so vulnerable that even all
> the media hype over XML is still not enough?  Where is Darwin
> in all this?

The sentiment is correct here. My concern is not about XML's
survival, so much as about the necessity, or lack thereof
of a new syntax.

My gut feeling tells me that in the end, people will, over time,
tend to use XML in certain application domains in certain ways.
In the XML-for-data world, nobody will use external entities, or
internal subsets... and so, by application convention, they will
produce their own subset. That's fine by me (let a thousand
application subsets bloom). 

At some point in time, they may even decide that it's really 
necessary to codify the subset as a standard in and of itself. 
That's fine by me too (it happened a few times in the SGML
community).

That said, I think it's still early days: far too early to be
formally defining a subset for general use. I take the 
disagreement on this mailing list to be a sure sign of that.


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



From vlashua at RSGsystems.com  Tue Nov 30 22:32:56 1999
From: vlashua at RSGsystems.com (Vane Lashua)
Date: Mon Jun  7 17:18:07 2004
Subject: [SML] All I know is what I read  in the papers. -- Will Ro
	gers
Message-ID: <A51F7543E295D2118D6600A024CDB2F71B9D61@MAILPROD>

SML has been around for about 30 years. Actually I heard it was conceived at
the NSA in the earliest second-generation processing of inbound and domestic
telephone traffic in the US. The NSA created a voice-print XML dtd and an
OODBMS, but found the processing was too intense. A young analyst, Yuri
Rubinsky [working on a Canadian green card], proposed SML to remedy that.
The database stored native SML structures and binary objects encrypted and
compressed with the V2 modification of Enigma. I heard it was developed in
an early version of Java by Charles Goldfarb based on Donald Knuth's work on
stochastic TEX written in Web (where do you think he got his ideas?).
Personally I have never actually used or seen SML myself, I'm sure the
standard exists somewhere though I may be thinking of ALGOL. [Former NSA or
xml.com employees, help me out here...]

-----Original Message-----
From: Leigh Dodds [mailto:ldodds@ingenta.com]
Sent: Tuesday, November 30, 1999 7:16 AM
To: Oren Ben-Kiki; xml-dev
Subject: RE: (retry) Re: [SML] Whether to support Attribute or not?


> It isn't yet clear that SSLT is viable, even assuming SML is.

>From the XML.com article:
"Since a Simple Markup Language is already a reality in many applications,
there is some urgency to setting the standard in place. Such a standard is
not
likely to be difficult to define, nor is there good reason for it to be
particularly controversial, so it should not take long for it to appear.
Expect to see the draft no later than mid-December and a standard by
January."
http://www.xml.com/pub/1999/11/sml/index.html

Until I read that, I thought SML was (largely) a research exercise on
Don's part - and we were all waiting to see whether he'd have to
eat the spec for breakfast or not. Will it or won't it fly. The
above quote suggests that it will, and that its actually going
to be a standard.

> We might settle on simply using XSLT on SML input.

> There's no reason we _must_ write the stylesheets in SML.

This is the nub of my confusion - if SML is for palmtops
or other devices, then we must write the stylesheets
in SML because such devices apparently can't cope with
an XML parser (and certainly not an XML parser for XSLT processing,
and an SML parser for the rest).

But then we're still not entirely sure where (or if) SML is going to
be deployed.

> Other XML specs don't have this option. How would one handle XLink in SML?

And what about XPath - the attribute related syntax might be redundant
if that removed from SML, so we can start simplifying there too, right?

I'm not knocking the SML effort per se, just trying to get a feel
for the scope of the endeavour. Its also hard to judge its progress
because there are no use-cases, milestones or requirements to
judge it against.

There are multiple definitions of 'simple'. Which one, specifically,
is SML working towards? Don suggested "minimal, and easy"
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Nov-1999/1163.html
Can we quantify that further - or will that happen when
the grammar has been finalised?

Cheers,

L.

p.s. Egg/face interface ready, as is my flame-proof jacket :). I'm
really just curious...


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



From jes at kuantech.com  Tue Nov 30 23:14:30 1999
From: jes at kuantech.com (Jeffrey E. Sussna)
Date: Mon Jun  7 17:18:07 2004
Subject: XML processing instruction survey
Message-ID: <000b01bf3b87$b13c5c50$0f36a8c0@quokka.com>

I'm interested in the extent to which people are actually using the XML
processing instruction ( <?xml ) in their XML files, and the extent to which
they find it useful.

Jeff Sussna


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



From oig4f at tetra.mail.virginia.edu  Tue Nov 30 23:53:17 1999
From: oig4f at tetra.mail.virginia.edu (Olya Gurevich)
Date: Mon Jun  7 17:18:07 2004
Subject: [SGREP][Win]Bugs in the Win32 binary of Sgrep 1.91a
In-Reply-To: <Pine.GSO.3.96.991130123928.27016B-100000@isis>
Message-ID: <Pine.A41.4.05.9911301845520.75456-100000@node4.unix.Virginia.EDU>

I am trying to use the windows binary of sgrep 1.91a to search XML texts.
Here are some of the problems I run into:
1) If I use a keyword in the search expression (e.g. 
	sgrep -o "%s %e\n" "elements" simple.xml, or
	sgrep -o "%s %e\n" "word(\"title\")" simple.xml
  the program fails with with a memory access violation

2) If I try to perform a search on an entire directory, the command-line
is not parsed correctly.  E.g. a search like
	sgrep -o "%s %e\n" "\"title\"" *.xml

fails with the error "*.xml: Argument not found"

These problems seem to be unique to the windows binary.  Has anyone found
a way around them, or recompiled the source code to fix these bugs?

Thanks!
Olya Gurevich
oig4f@virginia.edu


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