From tbray at textuality.com  Sun Nov  1 03:21:14 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
Message-ID: <3.0.32.19981031192043.00b1b200@pop.intergate.bc.ca>

At 10:36 AM 10/30/98 -0500, david@megginson.com wrote:
>So, Henry's asking whether this is valid:
>
>  <!DOCTYPE a [
>    <!ELEMENT a (b, c)>
>    <!ELEMENT b EMPTY>
>    <!ELEMENT c EMPTY>
>  ]>
>  <a><![CDATA[  ]]><b/><c/></a>
>
>I'd like to hear Tim Bray's opinion, unless I've missed it already in
>this thread (are you reading this, Tim, or alternatively, do you have
>an e-mail filter that looks for your name?).

Yes and no, respectively.  I've been lurking, hoping that someone
would post something definitive.  

The more I think about it, the more I think it's valid, because white
space between child elements is OK, and the fact that the white space
is in a CDATA section doesn't mean it's not white space.  Chris
Lovett argued that it would be OK if the white space were in
an entity reference, which I think is a strongly linked problem (although
I couldn't follow Chris' reasoning about why MSXML thinks this the
CDATA section is invalid).  Larval agrees with me, by the way, because 
the CDATA recognizer does its work first and the validator only ever sees 
white space.

However, the rule that applies is section 3., validity constraint
"Element Valid", list item 2, which I quote:

 2. The declaration matches children and the sequence of child elements 
    belongs to the language generated by the regular expression in the 
    content model, with optional white space (characters matching the 
    nonterminal S) between each pair of child elements. 

Of course, the interpolation "(characters matching the nonterminal S)"
could lead a pedant to claim that "<![CDATA[" doesn't match S, so there
you go.  So if only on these grounds, David's claim that the spec should
be clarified in this respect has some merit.

I must say I'm somewhat pleased by the fact that there are voices
in xml-dev simultaneously saying "The spec needs to be rewritten in
clear, limpid, prose" singing counterpoint with others saying "The 
spec needs to be rewritten in formal logic".  On the same grounds that 
if both the IRA and the Unionist paramilitaries are denouncing you, 
you're probably doing the right thing.  Actually, both factions have a 
point.  The writing in the spec could be better, and so could the
formalism.  It was the best Michael and I, with the committee's support,
could do in the time available, and it's been enough to limp along
with so far.

I do *not* agree that XML won't come into its own until we bypass
all the syntax and think only in terms of abstract data structures.
Having watched this profession for 20 years ago, I have come to
believe that a truly interoperable API is very nearly an oxymoron;
but syntax is something we know how to interoperate with.  Also I 
just don't believe that there is One True data model for 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Sun Nov  1 03:55:12 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000001be0498$180e4100$b3e887cb@NT.JELLIFFE.COM.AU>
Message-ID: <363BDAB1.26A13201@eng.sun.com>

As another data point -- Sun's validating parser accepts Henry's
original example, no problems.  (And it does so very quickly,
but you knew that!  ;-)

A pragmatic answer "why":  it uses the data model implied by
SAX, which treats characters "quoted" by "<![CDATA[" ... "]]>"
like any other characters (but without using '&' and '<' as
markup delimiters).

I think that's the right model.  It's clear from 2.7 that the
text inside a CDATA section is character data, not markup; the
example is clear, if the text could be misunderstood.

Since 2.4 makes clear (sentence 1!) that the _only_ two sorts
of stuff in XML are "character data" and "markup", so there's
no way I could justify treating space inside a CDATA section
differently from other characters (in terms of data model).
Hence it's not possible to distinguish whitespace characters
that are the content of a CDATA section from the same text
that's outside of a CDATA section.

- Dave

p.s. Yes, if there's confusion, the spec probably needs to
	be clarified.  Not a crime in any 1.0 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Sun Nov  1 04:15:17 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000001be0498$180e4100$b3e887cb@NT.JELLIFFE.COM.AU>
Message-ID: <363BDF62.3B59998D@eng.sun.com>

Rick Jelliffe wrote:
> 
> 	 marked sections actually mark up
> notations: at ISO there has been discussion of whether to allow something
> like (for example)
>         <![JAVA[ java code here ]]>

While I applaud the ongoing proliferation of real Java(tm), I admit I
don't like that either ... <Java><![CDATA[ java code ]]></Java> has
worked just as well, and does no damage to XML.  (Not as pretty though!)


> This is not something that I would expect to make its way into XML (and I
> think the ISO people are now more keen to help XML/WebSGML than on tidying
> up SGML) but I think the idea that a marked section

... but XML has only "CDATA" sections.  There's no such thing as
a "marked" section, and "CDATA" is specified to be character data
terminated by a "]]>" sequence.  No notion of marking/labeling.


>	 not only alters
> delimiter recognition but also labels the data can be seen (in embryo or
> residually) in DOMs elevation of CDATAsection to node-worthiness, which has
> so perplexed Henry.

Keep in mind that DOM implementations are not required to import
an XML document using CDATASection nodes ... Sun's just uses it
to determine _how to write out_ the text, if someone adds such a
node to a DOM tree they've constructed.  The "<" and "&" markup
delimiters don't get quoted like they must be for normal text,
and "]]>" gets funkified differently.


> I think the answer is clear from the spec:
> [43]  content ::=  (element | CharData | Reference | CDSect | PI | Comment)*
> so a CDSect is not CharData. Therefore a CDSect is only valid in mixed
> content, even though it is well-formed to have it in element content.

I can't buy that conclusion.  Among other things, that production has
no constraints relating to "mixed content".  Is this an argument that
cosmetic whitespace, comments, and PIs likewise must exist only inside
mixed content?

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  1 06:15:14 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <363BDAB1.26A13201@eng.sun.com>
Message-ID: <000001be055f$2a480eb0$abe887cb@NT.JELLIFFE.COM.AU>


> From:   David Brownell

> A pragmatic answer "why":  it uses the data model implied by
> SAX, which treats characters "quoted" by "<![CDATA[" ... "]]>"
> like any other characters (but without using '&' and '<' as
> markup delimiters).

Aha! I think this is the big difference in approach. The David's are saying
that CDATAsects are tags which switch in and out an effect, while I am
saying that the CDATAsect is markup which delimits a range and labels it.

Personally, I hope CDATAsects are removed from the mooted XML profile (does
it have a code name? EZX?), I have never thought they were a particularly
good idea. But I guess they wont be, in that it would make it possible to
generate EZX documents which were not WF XML documents. [I'd guess EZX would
remove DTDs (no entities!), make UTF-8 the only charset, allow but deprecate
PIs (in particular before and after fragments or root-elements), allow but
deprecate CDATAsects, build-in the ISO public entity sets with HTMLsymbols,
and build-in namespaces. I suppose this would then become the syntax used
for HTML 5, or whatever HTML+XML is called. That would be a nice little
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov  1 16:58:56 1998
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <000001be0498$180e4100$b3e887cb@NT.JELLIFFE.COM.AU>
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk>
Message-ID: <199811011654.IAA02758@sqwest.bc.ca>

On 31 Oct 98, at 17:31, Rick Jelliffe wrote:

> Henry Thompson wrote:
> 
> > The DOM made a serious mistake here in my opinion: it's
> > stranded in no-person's-land between raw and cooked, without being
> > either.  It's not cooked, because it gives you EntityReference and
> > CDATA nodes.  It's not raw, because it DOESN'T give you character
> > entity references.
> 
> CHARACTER REFERENCES
> I think Henry means "numeric character reference", and this is the heart
> of the matter. A numeric character is not an entity, any more than a
> directly-entered character is. It is just an alternative encoding of the
> character, and should be of no more interest to a general API than the
> charset encoding of the document was. (I am putting words into his mouth:
> or does Henry mean the [XMLs4.6] predefined entities?)

This is the reason that the DOM doesn't give you access through 
the DOM to the numeric characters. It's perfectly acceptable for the 
application to give access if it's necessary for that application, but 
the DOM WG, after a *lot* of discussion, decided that the 
alternative encodings of a document were not up to the DOM to 
decide.

As for CDATA sections and the DOM - we decided that the DOM 
could not, in and of itself, decide whether the CDATA section was 
purely an escaping mechanism that the application (such as an 
editor) could use or not as it chose or whether the CDATA section 
had deeper significance. Making CDATA sections nodes means 
that the application can choose which is true. If the CDATA section 
is simply an escaping mechanism, then the data can be 
transformed before being passed to the DOM, in which case the 
DOM will never see a CDATA section. Should the CDATA section 
have some other significance, the parser can leave it as a CDATA 
section and pass it to the DOM, which will respect it.


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


From papresco at technologist.com  Mon Nov  2 00:10:58 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca>
Message-ID: <363CF738.C389AB26@technologist.com>

Lauren Wood wrote:
> 
> If the CDATA section
> is simply an escaping mechanism, then the data can be
> transformed before being passed to the DOM, in which case the
> DOM will never see a CDATA section. Should the CDATA section
> have some other significance, the parser can leave it as a CDATA
> section and pass it to the DOM, which will respect it.

Is there a standard way for the DOM client software to say whether it
wants access to CDATA sections or not?

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

"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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  2 00:48:58 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:08 2004
Subject: Optional Nodes in the DOM
In-Reply-To: <363CF738.C389AB26@technologist.com>
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk>
	<199811011654.IAA02758@sqwest.bc.ca>
	<363CF738.C389AB26@technologist.com>
Message-ID: <13884.65089.320319.709774@localhost.localdomain>

Paul Prescod writes:

 > Is there a standard way for the DOM client software to say whether it
 > wants access to CDATA sections or not?

I don't think so -- I'd imagine that that would have to be an option
to the DOM builder, which is left unspecified.  I could imagine
something like this:


  public class DOMFactory
  {
    public final static int NONE = 0;

                        // Optional node types
    public final static int COMMENTS = 1;
    public final static int ENTITYREFS = 2;
    public final static int CDATA = 3;
    public final static int ALL = COMMENTS | ENTITYREFS | CDATA;

    public Document createDocument (int flags)
      throws DOMFactoryException, IOException; // etc.
  }

and then

  Document doc = factory.createDocument(DOMFactory.NONE);

I can also imagine many DOM builders that always leave these nodes
types out, since that information is not needed for most XML
applications (authoring and repository tools excepted).


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  2 01:07:27 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:08 2004
Subject: Optional Nodes in the DOM
Message-ID: <3.0.32.19981101170427.00b28950@pop.intergate.bc.ca>

At 07:47 PM 11/1/98 -0500, david@megginson.com wrote:
>I can also imagine many DOM builders that always leave these nodes
>types out, since that information is not needed for most XML
>applications (authoring and repository tools excepted).

Well, authoring anyhow. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 quake.net  Mon Nov  2 02:17:01 1998
From: donpark at quake.net (Don Park)
Date: Mon Jun  7 17:06:08 2004
Subject: ANN: XML-APP Mailing List
Message-ID: <007c01be0606$b0af9520$2ee044c6@arcot-main>

I would like to announce the opening of the XML-APP mailing list.

WHAT:

XML-APP is a mailing list specifically for those interested in applying the
XML technology to real world applications.  It is not a place to discuss
general XML issues nor is it a place for the naive.

WHY:

I have felt that the quality of messages on the XML-DEV mailing list was too
high and too esoteric to encourage sharing of information among those who
are experienced enough to see the value of XML at first glance yet don't
give a hoot about things like architectural forms.  In other words, it is
difficult for carpenters to talk shop while architects are about.

HOW:

You can subscribe by sending a blank message to:

    mailto:xml-app-subscribe@sunsite.auc.dk

The mailing list itself is at:

    mailto:xml-app@sunsite.auc.dk

BUT:

It is my opinion that XML-DEV is the center of all XML activities.  I have
been and will continue to be an active member of the XML-DEV community.
XML-APP should be considered a subgroup of XML-DEV community and never as a
competing mailing list.

FYI:

XML-APP is being hosted by SunSITE Denmark.  List owners are Don Park of
Docuverse and J?rgen Nielsen of SunSITE Denmark.

Best,

Don Park
Docuverse



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From lauren at sqwest.bc.ca  Mon Nov  2 02:17:38 1998
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:06:08 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <363CF738.C389AB26@technologist.com>
Message-ID: <199811020212.SAA03758@sqwest.bc.ca>

On 1 Nov 98, at 18:05, Paul Prescod wrote:

> Lauren Wood wrote:
> > 
> > If the CDATA section
> > is simply an escaping mechanism, then the data can be
> > transformed before being passed to the DOM, in which case the
> > DOM will never see a CDATA section. Should the CDATA section
> > have some other significance, the parser can leave it as a CDATA
> > section and pass it to the DOM, which will respect it.
> 
> Is there a standard way for the DOM client software to say whether it
> wants access to CDATA sections or not?

No. If people think it would be useful, we could potentially add 
some sort of "turn CDATA section into Text" method (and/or vice 
versa) in Level 2. Then the DOM client could run that before 
accessing the data. I'm not sure how else we could determine 
access without losing information (I assume you don't mean that 
information in the CDATA sections should be invisible to the client 
application).




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


From jborden at mediaone.net  Mon Nov  2 02:41:48 1998
From: jborden at mediaone.net (Borden, Jonathan)
Date: Mon Jun  7 17:06:09 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <199811020212.SAA03758@sqwest.bc.ca>
Message-ID: <001c01be060a$35c316d0$d3228018@jabr.ne.mediaone.net>

Lauren Wood wrote:

>
> No. If people think it would be useful, we could potentially add
> some sort of "turn CDATA section into Text" method (and/or vice
> versa) in Level 2. Then the DOM client could run that before
> accessing the data. I'm not sure how else we could determine
> access without losing information (I assume you don't mean that
> information in the CDATA sections should be invisible to the client
> application).
>

	Alternatively, you can expose both CDATA as an element of type CDATA and as
text within the TEXT element. This would preserve the intended behavior
w.r.t. text as well as allowing the option of iterating over CDATA elements
for interested parties.

Jonathan Borden
JABR Technology
http://jabr.ne.mediaone.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Mon Nov  2 04:36:02 1998
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:06:09 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <001c01be060a$35c316d0$d3228018@jabr.ne.mediaone.net>
References: <199811020212.SAA03758@sqwest.bc.ca>
Message-ID: <199811020431.UAA03914@sqwest.bc.ca>

On 1 Nov 98, at 21:40, Borden, Jonathan wrote:

>  Alternatively, you can expose both CDATA as an element of type CDATA and
>  as
> text within the TEXT element. This would preserve the intended behavior
> w.r.t. text as well as allowing the option of iterating over CDATA
> elements for interested parties.

Both CDATASection and Text inherit from CharacterData. Is this 
what you mean? Alternatively, you could use the flattening 
properties from Node and just look for NodeValue on each. This 
returns the content of each node without the need for casting.


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


From rbourret at ito.tu-darmstadt.de  Mon Nov  2 09:09:28 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:09 2004
Subject: XSchema 1.0 released
Message-ID: <01BE0648.3348E5E0@grappa.ito.tu-darmstadt.de>

XSchema 1.0 is now final.  Thanks to everyone on XML-Dev who helped make it a reality, and especially to Simon St. Laurent for getting the ball rolling.  You can find the general XSchema page at:

   http://purl.oclc.org/NET/xschema

and the final spec at:

   http://www.simonstl.com/xschema/spec/xscspecv5.htm

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From aheitor at ef.pt  Mon Nov  2 14:47:31 1998
From: aheitor at ef.pt (Ana Heitor)
Date: Mon Jun  7 17:06:09 2004
Subject: xsl... tables... colspan...
Message-ID: <Pine.LNX.3.96.981102141616.31659A-100000@hercules.ef.pt>

Hi,


Someone can tell me, how can I write rules in xsl for:

1) have two tables;

2) One table with a variable number of columns.

For example:

<rule>
	<element type="tag1">
	<element type="tag2">
		<target-element type="tag3"/>
	</element>
	</element>
	
	<td colspan="2"><children/></td>
</rule>

I want evaluate the colspan dynamicaly in function of columns number.

Thanks

AH





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simpson at polaris.net  Mon Nov  2 15:04:57 1998
From: simpson at polaris.net (John E. Simpson)
Date: Mon Jun  7 17:06:09 2004
Subject: xsl... tables... colspan...
Message-ID: <3.0.32.19981102100504.006a6a2c@polaris.net>

Ana --

At 02:43 PM 11/2/98 +0000, Ana Heitor wrote:
>	[Question about XSL rules]

You might find a quicker answer to your question on the XSL mailing list.
Information on joining it, and the archives, are at:
	http://www.mulberrytech.com/xsl/xsl-list

Good luck!

=============================================================
John E. Simpson          | It's no disgrace t'be poor, 
simpson@polaris.net      | but it might as well be.
                         |            -- "Kin" Hubbard

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Mon Nov  2 15:28:47 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:09 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com>
Message-ID: <363DCFB4.36A59E21@locke.ccil.org>

Paul Prescod wrote:

> Is there a standard way for the DOM client software to say whether it
> wants access to CDATA sections or not?

No.  In fact, the DOM level 1 does not define any API for the
creator, only for the accessor.  You can add elements and other
things, but you can't create or populate a DOM using only the
standard API.

DOM Level 1 is an ugly mess, and the only justification for it
is to keep Netscape and Microsoft from implementing even uglier
incompatible DOMs.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Mon Nov  2 15:32:00 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:09 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <001c01be060a$35c316d0$d3228018@jabr.ne.mediaone.net>
Message-ID: <363DD08C.1A11CAE8@locke.ccil.org>

Borden, Jonathan wrote:

> Alternatively, you can expose both CDATA as an element of type CDATA and as
> text within the TEXT element. This would preserve the intended behavior
> w.r.t. text as well as allowing the option of iterating over CDATA elements
> for interested parties.

Actually, the only thing you can do with a Text node that you can't
do with a CDATA node is merge it with an adjacent Text node, a very
minor capability which can easily be simulated.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From bckman at ix.netcom.com  Mon Nov  2 16:10:58 1998
From: bckman at ix.netcom.com (Frank Boumphrey)
Date: Mon Jun  7 17:06:09 2004
Subject: DTD,s
Message-ID: <008401be067b$4db05b60$3bacdccf@ix.netcom.com>

Does any one know of a site where XML dtd's are available for general use?

If not
1.Would there be a need for such a site.
2.Would anyone be prepared to donate some dtd's to such a site.

I have several xml dtd's including xml dtd's for html strict and
transitional that I could make available.

regards,
Frank
Frank Boumphrey

XML and style sheet info at Http://www.hypermedic.com/style/index.htm
Author: - Professional Style Sheets for HTML and XML http://www.wrox.com
CoAuthor: Professional XML applications form Wrox Press, www.wrox.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From richard at cogsci.ed.ac.uk  Mon Nov  2 16:28:51 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:09 2004
Subject: CDATA by any other name... (was The raw and the cooked)
Message-ID: <199811021628.QAA09805@cogsci.ed.ac.uk>

One reason to regard a CDATA section as equivalent to the characters
in it is that it is prefectly reasonable for a processor to transform
a CDATA section into plain character data with character entities
where required.  A processor that outputs canonical XML will do this.

Suppose we regard <![CDATA[ ]]> as invalid in element-only content.
If the processor is non-validating, it will not check this, and
will produce valid output from invalid input.

You might for example run a document through such a processor merely
to change its character encoding.  It would be unfortunate if this
process changed the document's validity.

Slightly less plausibly, a processor might decide to output all character
data as CDATA sections to avoid using character entities.  This process
could make a valid document invalid.

-- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  2 16:46:47 1998
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:06:09 2004
Subject: DTD,s
Message-ID: <006001be067f$f4ec6960$0300000a@othniel.cygnus.uwa.edu.au>

-----Original Message-----
From: Frank Boumphrey <bckman@ix.netcom.com>

>Does any one know of a site where XML dtd's are available for general use?

That is what schema.net is for. At present it is a catalogue but will soon
house DTDs.
(Actually it already has an increasing number of entities, thanks to Rick
Jelliffe)

It also has an SGML Open catalog that uses my delegate idea to allow
resolution of formal public identifiers. The XBEL DTD developed by the
Python XML-SIG has already made use of this.

>I have several xml dtd's including xml dtd's for html strict and
>transitional that I could make available.


Send them my way and I'll add them to schema.net.

James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Associate Researcher, Electronic Commerce Network
Curtin University of Technology, Perth, Western Australia

Maintainer of : www.xmlinfo.com,  www.xmlsoftware.com and www.schema.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Mon Nov  2 17:25:53 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:09 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org>
Message-ID: <363DE9F3.2EDF9979@eng.sun.com>

John Cowan wrote:
> 
> DOM Level 1 is an ugly mess, and the only justification for it
> is to keep Netscape and Microsoft from implementing even uglier
> incompatible DOMs.

I think everyone recognizes some of the compromises that went
into DOM, and has a list of some mistakes they'd fix.  But I
don't think there's a good consensus on which things are mistakes
rather than features ...

To put it differently:  is there really room for another API
to represent XML structure?

I tend to think that DOM, warts and all, is "good enough" for
most purposes.  And for those other purposes, I suspect that
no standard API could suit.

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 sunsite.unc.edu  Mon Nov  2 17:43:17 1998
From: elharo at sunsite.unc.edu (Elliotte Rusty Harold)
Date: Mon Jun  7 17:06:09 2004
Subject: Web pages in non-Roman scripts
In-Reply-To: <TFSOVBGZ@dpsl.co.uk>>
Message-ID: <v03102803b26399a36d4f@[168.100.203.234]>

For my next book about XML I am seeking examples of Web pages in non-Roman
scripts: Cyrillic, Greek, Chinese, Japanese, etc.  The purpose is to
include before and after screen shots showing them with and without the
proper fonts and encodings. If you maintain such a web site, and you're
willing to sign a permissions form dreamed up by IDG's lawyers, please
email me the URL, your snail mail address and FAX number and I'll send you
the permissions letter to sign. To thank you for your trouble, I'll also
send you a copy of my current book--XML: Extensible Markup Language--when I
get the signed permission agreement back. Finally, if your site is included
in the finished book (sites will also have to be approved by my editors)
I'll also send you a copy of the next book when it's published.

Pretty much any site in a non-Roman script will do. However, I do have a
preference for interesting pages like one discussing China's human rights
record in Chinese or the text of War and Peace in Russian, as opposed to
corporate home pages.  But I'll take whatever I can get. If you're
interested, please send private email to elharo@sunsite.unc.edu. Thanks.


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


From eddie.sheffield at enterworks.com  Mon Nov  2 19:39:47 1998
From: eddie.sheffield at enterworks.com (Eddie Sheffield)
Date: Mon Jun  7 17:06:09 2004
Subject: DTD,s
References: <006001be067f$f4ec6960$0300000a@othniel.cygnus.uwa.edu.au>
Message-ID: <363E08D0.C0390CDD@enterworks.com>

James Tauber wrote:

> -----Original Message-----
> From: Frank Boumphrey <bckman@ix.netcom.com>
>
> >Does any one know of a site where XML dtd's are available for general use?
>
> That is what schema.net is for. At present it is a catalogue but will soon
> house DTDs.
> (Actually it already has an increasing number of entities, thanks to Rick
> Jelliffe)

There is also the CommerceNet XML Exchange at http://www.xmlx.com that claims to
have the same purpose, but I've been checking on them for several months now and
there is absolutely no action there. Lack of promotion, I guess. But it is
organized around forums (such as Automotive, History, Genealogy, Workflow, etc.),
apparently with the notion that people would come together, post DTDs, and
actively develop them online. But except for September archives which only
contain the forum welcome messages, there is nothing.

Does anyone know of anywhere else where one can go to discuss the development of
DTDs? XML Exchange sounded perfect, but there are not really any appropriate
catagories for my ideas, and there was no response to my request to create a new
"Household" or "Consumer" forum. I have several home user ideas I'd like to see
fleshed out - recipes, grocery lists, collections (stamps, comics, etc.), TV
listings, etc. but I don't really have the experience in DTD design to tackle it.
Maybe I need to tackle David's (Megginson) book again. ;-)

BTW, did anyone ever give any references for "Z" from the recent CDATA thread? My
curiosity is perked, but I have a feeling searching for "Z" on Hotbot or Yahoo or
wherever would prove frustrating!

Thanks.

Eddie Sheffield



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From hussain at granularity.com  Mon Nov  2 20:02:08 1998
From: hussain at granularity.com (G. Hussain Chinoy)
Date: Mon Jun  7 17:06:10 2004
Subject: DTD,s
In-Reply-To: <008401be067b$4db05b60$3bacdccf@ix.netcom.com>
Message-ID: <Pine.LNX.3.96.981102135500.17920I-100000@kehl.tleilax.com>



Are people aware of this site?

        A repository of public sgml/xml texts
        http://www.ucc.ie/cgi-bin/PUBLIC

	which is referenced on...

        The SGML/XML Web Page (robin cover): XML/SGML Name Registration
        http://www.oasis-open.org/cover/xml.html#xmlNameRegistry

	and related to..

        The GCA's public identifier registration process
        http://www.gca.org/publicid/
-----------------------------------------
G. Hussain Chinoy
hussain@granularity.com
Chief Information Architect, CEO
Granularity Information Architecture, Inc.
http://www.granularity.com/

On Mon, 2 Nov 1998, Frank Boumphrey wrote:

> Does any one know of a site where XML dtd's are available for general use?
> 
> If not
> 1.Would there be a need for such a site.
> 2.Would anyone be prepared to donate some dtd's to such a site.
> 
> I have several xml dtd's including xml dtd's for html strict and
> transitional that I could make available.
> 
> regards,
> Frank
> Frank Boumphrey
> 
> XML and style sheet info at Http://www.hypermedic.com/style/index.htm
> Author: - Professional Style Sheets for HTML and XML http://www.wrox.com
> CoAuthor: Professional XML applications form Wrox Press, www.wrox.com
> 
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From DKACKMAN at agchem.com  Mon Nov  2 21:11:08 1998
From: DKACKMAN at agchem.com (Don Kackman)
Date: Mon Jun  7 17:06:10 2004
Subject: Retrieving attributes from an internal entity
Message-ID: <8424EFA3C1F7D1118B7300A0C9C57C192084D4@mpl_nt9.agchem.com>

Hello,

I'm using Microsoft's XML parser that comes as part of IE 5 beta 1 as a
component of an application that will use XML as its document format.
Since IE5 is still a beta I'm having some trouble determining if certain
behaviors are bugs in the current version of their parser or correctly
reflect the W3C specification.

Namely I'm using an internal entity declaration as follows:

<!ENTITY om "<variable targetset='om'>OM</variable>">

as part of the internal part of the DTD.

I can load the document into MSXML (thier parser) and traverse the node
tree. When I get to the node where I am refering to the &om; entity I
get OM back as the value of that node but I cannot retrieve the
targetset attribute.

It is my understanding that internal entities should be parsed in place
when they are refered to, which should mean that I can treat that node
as I would any other. This does not seem to be the case with the MS
parser.

Is this a limitation of the MS beta parser or am I misunderstanding how
entities are used in XML?

Thank you,

Don Kackman
dkackman@agchem.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Mon Nov  2 21:17:52 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:10 2004
Subject: Retrieving attributes from an internal entity
Message-ID: <3.0.32.19981102131628.00aef4a0@pop.intergate.bc.ca>

At 03:10 PM 11/2/98 -0600, Don Kackman wrote:
><!ENTITY om "<variable targetset='om'>OM</variable>">
>
>I can load the document into MSXML (thier parser) and traverse the node
>tree. When I get to the node where I am refering to the &om; entity I
>get OM back as the value of that node but I cannot retrieve the
>targetset attribute.
>
>Is this a limitation of the MS beta parser or am I misunderstanding how
>entities are used in XML?

You're fine, you should be able to retrieve that attribute.  You
should report this back to Microsoft ASAP, I'm sure they'll fix it. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From DKACKMAN at agchem.com  Mon Nov  2 21:37:28 1998
From: DKACKMAN at agchem.com (Don Kackman)
Date: Mon Jun  7 17:06:10 2004
Subject: Retrieving attributes from an internal entity
Message-ID: <8424EFA3C1F7D1118B7300A0C9C57C192084D6@mpl_nt9.agchem.com>

Thanks for the quick reply Tim. 

How about this one...

I'm declaring the following entity:

<!ENTITY pct "<unit name='Percent' symbol='%'/>">

When I try to load this with MSXML I get this error:

A name was started with an invalid character.
Line 0000003: ...getset='om'><unit name='Percent'
symbol='%'/>OM</variable>">
Pos  0000070: ...------------------------------------------^

If I change % to any other character it loads fine. Can I use the %
symbol in an entity declaration? I suspect it thinks I'm trying to
insert a parameter entity.

Thanks again,

Don


-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]
Sent: Monday, November 02, 1998 3:18 PM
To: Don Kackman; 'XML Dev'
Subject: Re: Retrieving attributes from an internal entity


At 03:10 PM 11/2/98 -0600, Don Kackman wrote:
><!ENTITY om "<variable targetset='om'>OM</variable>">
>
>I can load the document into MSXML (thier parser) and traverse the node
>tree. When I get to the node where I am refering to the &om; entity I
>get OM back as the value of that node but I cannot retrieve the
>targetset attribute.
>
>Is this a limitation of the MS beta parser or am I misunderstanding how
>entities are used in XML?

You're fine, you should be able to retrieve that attribute.  You
should report this back to Microsoft ASAP, I'm sure they'll fix it. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Philippe.Le_Hegaret at sophia.inria.fr  Tue Nov  3 01:23:28 1998
From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret)
Date: Mon Jun  7 17:06:10 2004
Subject: ANN: KOML 1.1 released
Message-ID: <363E5B04.FA5AF290@sophia.inria.fr>

KOML is an XML application to serialize Java Objects
in an XML document. This application is called KOML
for Koala Object Markup Language.

This new version includes bug fix and a minor 
change in the language. It is backward compatible
with the version 1.0 .

values (except transient) have a name attribute.
  (thanks to Robert Nielsen for his feedback) 
Bug fix with Class objects. 
Bug fix in close() methods. (thanks to Raj)
Remove File constructors. Now you have: 
   KOMLSerializer(Writer out, boolean buffered) 
   KOMLDeserializer(Reader out, boolean buffered) 


A new KOML document :

<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE koml SYSTEM "http://www.inria.fr/koala/XML/koml11.dtd">
<koml version='1.1'>
 <classes>
  <class name='java.net.URL' uid='-7627629688361524110' writemethod='true'>
   <field name='hashCode' type='int'/>
   <field name='port' type='int'/>
   <field name='file' type='java.lang.String'/>
   <field name='host' type='java.lang.String'/>
   <field name='protocol' type='java.lang.String'/>
   <field name='ref' type='java.lang.String'/>
  </class>
 </classes>
 <object class='java.net.URL' id='i5'>
  <value type='int' name='hashCode'>-1</value>
  <value type='int' name='port'>-1</value>
  <value type='java.lang.String' name='file'>/koala</value>
  <value type='java.lang.String' name='host'>www.inria.fr</value>
  <value type='java.lang.String' name='protocol'>http</value>
  <null name='ref'/>
 </object>
</koml>


Regards,
Philippe.
---------
Philippe Le Hegaret
Philippe.Le_Hegaret@sophia.inria.fr -- http://www.inria.fr/koala/plh/
KOALA/DYADE/BULL @ INRIA - Sophia Antipolis

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jtauber at jtauber.com  Tue Nov  3 01:34:23 1998
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:06:10 2004
Subject: Z references (was Re: DTD,s)
Message-ID: <00fb01be06c9$b0228cc0$0300000a@othniel.cygnus.uwa.edu.au>

-----Original Message-----
From: Eddie Sheffield <eddie.sheffield@enterworks.com>
>BTW, did anyone ever give any references for "Z" from the recent CDATA
thread? My
>curiosity is perked, but I have a feeling searching for "Z" on Hotbot or
Yahoo or
>wherever would prove frustrating!


Yahoo was easy. Try:

http://dir.yahoo.com/Computers_and_Internet/Programming_Languages/Z/

which leads to an excellent site:

http://www.comlab.ox.ac.uk/archive/z.html

James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Associate Researcher, Electronic Commerce Network
Curtin University of Technology, Perth, Western Australia

Maintainer of : www.xmlinfo.com,  www.xmlsoftware.com and www.schema.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jieli at cs.umbc.edu  Tue Nov  3 02:23:26 1998
From: jieli at cs.umbc.edu (Li Jiefeng)
Date: Mon Jun  7 17:06:10 2004
Subject: How to call JS function in .xsl file?
Message-ID: <Pine.SGI.3.96.981102211902.29618G-100000@retriever.cs.umbc.edu>

Hello,
	I am wondering how to call a JavaScript function in .xsl file.

	For instance,
	<SCRIPT LANGUAGE="JSCRIPT"><![CDATA[
		
		function abc(x)
		{
			document.writeln(" ... ");
		}
	]]>
	</SCRIPT>
 	
	...

	I tried 
		abc(x);
		<eval>abc(x)</eval>
		"=abc(x)"
	but all failed.

	Thx for your help.

Jiefeng
---------------------------------------------------------------------
                      Jiefeng Li, CSEE, UMBC
         (410)455-2837(L), (410)455-3094(O), (410)242-9610(H) 
		    http://www.cs.umbc.edu/~jieli



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Tue Nov  3 08:02:23 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:10 2004
Subject: Web pages in non-Roman scripts
In-Reply-To: <v03102803b26399a36d4f@[168.100.203.234]>
Message-ID: <000b01be0700$7d00c730$11e887cb@NT.JELLIFFE.COM.AU>



> From:   Elliotte Rusty Harold

> Pretty much any site in a non-Roman script will do. However, I do have a
> preference for interesting pages like one discussing China's human rights
> record in Chinese or the text of War and Peace in Russian, as opposed to
> corporate home pages.

Not much Chinese XML here in Taiwan yet, because of technology lag. There
are some interesting projects in the pipes though. I dont know about other
Chinese countries.

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


From M.H.Kay at eng.icl.co.uk  Tue Nov  3 10:39:46 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:10 2004
Subject: CDATA by any other name... (was The raw and the cooked)
Message-ID: <002301be0715$a205f680$7008e391@bra01wmhkay.bra01.icl.co.uk>

>I do *not* agree that XML won't come into its own until we bypass
>all the syntax and think only in terms of abstract data structures.
>Having watched this profession for 20 years ago, I have come to
>believe that a truly interoperable API is very nearly an oxymoron;
>but syntax is something we know how to interoperate with.  Also I
>just don't believe that there is One True data model for XML.


I agree that defining what is and is not well-formed and valid XML ought to
be a readily achievable goal, and it is a little surprising to find an area
where the spec is ambiguous on the matter. Hence my suggestion for a formal
analysis to discover whether there are other unsuspected problems.

I also agree that defining what a conformant XML processor should do with
that XML (not to mention what it should do with erroneous XML) is
considerably harder, though I think the problem becomes tractable if the
behaviour is defined in terms of a concrete API such as SAX or DOM.

I agree with those who have pointed out that formalisms like Z are not a
good vehicle for communicating a standard to a wide audience. In my own
experience, however, the kind of thinking required to produce a formal
specification in Z is invaluable when trying to produce an unambiguous one
in clear English. I don't believe that precision and readability are
incompatible goals.

There is information about Z, by the way, on
http://www.non.com/news.answers/z-faq.html

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Tue Nov  3 10:47:23 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:10 2004
Subject: CDATA by any other name... (was The raw and the cooked)
Message-ID: <002901be0716$b5121a50$7008e391@bra01wmhkay.bra01.icl.co.uk>

>> marked sections actually mark up
>> notations: at ISO there has been discussion of whether to allow something
>> like (for example)
>>         <![JAVA[ java code here ]]>
>
>While I applaud the ongoing proliferation of real Java(tm), I admit I
>don't like that either ... <Java><![CDATA[ java code ]]></Java> has
>worked just as well, and does no damage to XML.  (Not as pretty though!)


Neither really works well, because "]]>" can legitimately occur in a Java
program. For example, it is quite likely to occur in a Java program that
generates XML.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Tue Nov  3 11:52:09 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:10 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <002901be0716$b5121a50$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU>


A CDATA marked section is not only a way to prevent delimiter recognition.
It is also a way to declare that the characters in that section are limited
to ones available in the direct document encoding of the originating system.
(SGML has a CDATA keyword you can use instead of content models: XML was
felt not to need it because you could use <![CDATA[, however that perhaps
shows the mind of the XML WG at that time, in that they were down-playing
the need for schemas.) It declares "this section does not use character
references or entities or subelements". So, conceptually, it could sometimes
be markup, not merely delimiter recognition.

For example, I cannot see why a smart editor could not use the CDATA section
to cofine editing to whatever the repertoire of the character set of the
encoding attribute of the XML header says. In the case of editing the XML
specification, for example, when there is a CDATA marked section being
edited, and the editor types "<", a smart section should know not to replace
it with "&lt;" or expect it to be a STAGO. And if someone is editing a CDATA
marked section and uses a character that is not in the incoming encoding's
repertoire, I think it might be useful (to have an option to) warn the
data-enterer. This way, for example, it might be possible to constrain
document intended to interact with existing non-ISO10646 systems.

Of course, that might be useful, but whether it is so useful that XML should
keep to that way of thinking I dont know. I certainly dont think it is so
evil that it must be rejected outright.

(Apologies if this next part is getting too far off-topic)

> From:   Michael Kay
> Sent: Tuesday, 3 November 1998 21:43
> To: xml-dev@ic.ac.uk
> Subject: Re: CDATA by any other name... (was The raw and the cooked)
>
>
> >> marked sections actually mark up
> >> notations: at ISO there has been discussion of whether to
> allow something
> >> like (for example)
> >>         <![JAVA[ java code here ]]>
> >
> >While I applaud the ongoing proliferation of real Java(tm), I admit I
> >don't like that either ... <Java><![CDATA[ java code ]]></Java> has
> >worked just as well, and does no damage to XML.  (Not as pretty though!)
>
>
> Neither really works well, because "]]>" can legitimately occur in a Java
> program. For example, it is quite likely to occur in a Java program that
> generates XML.

The <![JAVA[ ]]> idea was not that JAVA would be a "CDATA marked section",
but an "RCDATA marked section", which means that special character
references and entity references would be allowed. XML does not have RCDATA
marked sections, in the interests of simplicity. So "]]>" might have been a
possibility for SGML, but it is not for XML.

Why have anything like this? The primary reason (apart from orthogonality)
to me is the contention that if you make element structure do too much, you
make the structure difficult to model with simple schema notations.

For example, think of a "wrapper" element type. (This is a pattern, by the
way.) For example, the RDF elements. Using a foreign wrapper element in a
document means that

* you will have to rewrite the content models in order to validate the
document. Or,
* you have to create a more complicated schema convention (e.g.,
  ** call the existing DTD an architecture and make it external, then use
the RDF DTD as the DTD of the current document and make dummy declarations
with ANY content models for all the old document or
  ** make up schema definition languages that rely on more than one level of
context)

But if, instead of a wrapper element, you used PIs for the wrappers, then
the content model is undisturbed, and the element structure keeps its
previous simplicity and the goals of its original authors. It would be nice
if W3C allowed this, but the less that a PI can be treated (by XLL or DOM or
SAX or whatever) as a kind of element, the less that this kind of simplicity
is possible. I have little sympathy for some of the people who say content
models are inexpressive, when they deliberately choose to ignore other the
markup options 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  3 12:01:31 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:10 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU>
References: <002901be0716$b5121a50$7008e391@bra01wmhkay.bra01.icl.co.uk>
	<000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU>
Message-ID: <13886.61181.97569.898100@localhost.localdomain>

Rick Jelliffe writes:

 > A CDATA marked section is not only a way to prevent delimiter
 > recognition.  It is also a way to declare that the characters in
 > that section are limited to ones available in the direct document
 > encoding of the originating system.  (SGML has a CDATA keyword you
 > can use instead of content models: XML was felt not to need it
 > because you could use <![CDATA[, however that perhaps shows the
 > mind of the XML WG at that time, in that they were down-playing the
 > need for schemas.) It declares "this section does not use character
 > references or entities or subelements". So, conceptually, it could
 > sometimes be markup, not merely delimiter recognition.

While I agree that there are always interesting new uses for markup
constructions, I think that we're straining here.  My basic rule in
system design is to keep things as simple and obvious as possible; if
I wanted to signal to my application that an element contained only a
certain type of information (such as a limited character repetoire), I
would use an attribute that made that point clear, either a NOTATION
attribute or a simple CDATA attribute named something like
"character-encoding".

That said, I don't see the usefulness of limiting content to a
specific character repetoire arbitrarily; I *do* see the usefulness in
combination with an "xml:lang" or "mime-type" attribute, though.  An
intelligent editor could already act on xml:lang to limit character
selection, if such a thing were desirable.


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


From north at Synopsys.COM  Tue Nov  3 13:00:16 1998
From: north at Synopsys.COM (Simon North)
Date: Mon Jun  7 17:06:10 2004
Subject: XML in IE5 beta PR2
In-Reply-To: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU>
References: <002901be0716$b5121a50$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <199811031257.NAA09118@goofy.gr05.synopsys.com>

Hi Gurus, 

I'm now experimenting with XML in IE5 beta preview release 2. It's 
nice to be able to parse the XML on load and to actually to be able 
to navigate the structure tree. It does, however, complain about not 
being able to load the XSL code (though it does seem to do a good job 
of supporting CSS). Has anyone got any further than this? 

Thanks, 

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


From papresco at technologist.com  Tue Nov  3 13:49:22 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org> <363DE9F3.2EDF9979@eng.sun.com>
Message-ID: <363F060D.47FB0E2C@technologist.com>

David Brownell wrote:
> 
> To put it differently:  is there really room for another API
> to represent XML structure?
> 
> I tend to think that DOM, warts and all, is "good enough" for
> most purposes.  And for those other purposes, I suspect that
> no standard API could suit.

I find it odd that we can have "standard APIs" for the full complexity of
relational data, and probably eventually for object database data, but it
is perceived to be impossible to do the same for the parse tree of XML
data. I mean it is just annotated tree structures: it shouldn't be rocket
science (but neither is it trivial).

No, we don't have such a thing yet, because it is not easy to develop and
nobody is willing to stop and think things through. Over time,
organizations like TechnoTeacher and ISOGEN *are* thinking it through. I
don't claim we've got the problem solved, but our direction is already
much more scalable, generalized and rigorous than what we are seeing in
the DOM realm.

Our approach is, we think, the same as the one taken by the relational
database people: first think of a model that supports the range of
applications that we want to support (including editing applications,
repositories, simple read-only processors) and data types that we want to
support (documents, DTDs, schemas, "link maps", vector and bitmap
graphics,... all media). Having defined the model, we need a way to
customize it for a particular application: a schema, just as they have
schemas in the relational and object database worlds. Our schemas are
property sets (the schema language needs to be stronger, if it is to
support read-write applications...we know that part needs work).

Then we develop an API to encapsulate the model. We are working on that
API right now.

Anyone who wants to follow our thinking can start with the tutorial on
groves at http://www.prescod.net/groves/shorttut As you can see from the
tutorial, the model is simpler than the relational model and yet seems
more or less complete (I know of one suggestion for enhancement). As I
said before, the schema language and the APIs are the parts that must
change now.

If there is a reason that this generalized approach *must* fail and cannot
be the basis of a variety of applications, then I would like to hear about
it sooner than later, so I invite comments from skeptics.

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

"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From richard at cogsci.ed.ac.uk  Tue Nov  3 14:16:01 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:11 2004
Subject: Retrieving attributes from an internal entity
In-Reply-To: Don Kackman's message of Mon, 2 Nov 1998 15:37:17 -0600 
Message-ID: <199811031414.OAA12936@cogsci.ed.ac.uk>

> <!ENTITY pct "<unit name='Percent' symbol='%'/>">

This is indeed being (correctly) interpreted as a malformed parameter
entity.  Use a character entity to refer to the percent character:

<!ENTITY pct "<unit name='Percent' symbol='&#37;'/>">

-- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  3 14:31:00 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:11 2004
Subject: Standard XML APIs (was Re: CDATA by any other name...)
In-Reply-To: <363F060D.47FB0E2C@technologist.com>
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk>
	<199811011654.IAA02758@sqwest.bc.ca>
	<363CF738.C389AB26@technologist.com>
	<363DCFB4.36A59E21@locke.ccil.org>
	<363DE9F3.2EDF9979@eng.sun.com>
	<363F060D.47FB0E2C@technologist.com>
Message-ID: <13887.4266.208216.446955@localhost.localdomain>

Paul Prescod writes:

 > I find it odd that we can have "standard APIs" for the full
 > complexity of relational data, and probably eventually for object
 > database data, but it is perceived to be impossible to do the same
 > for the parse tree of XML data. I mean it is just annotated tree
 > structures: it shouldn't be rocket science (but neither is it
 > trivial).

Let's divide the use of XML into two fairly arbitrary groups
(acknowledging that there's considerable overlap):

1. Documents
2. Data

Group #1 (documents) is characterised by long sequences of mixed
content inside block-level containers (often paragraphs, but possibly
subtasks or steps in technical documentation); group #2 (data) is
characterised by fairly rigid hierarchies with plain character data
inside named fields (often, but not always, short) appearing in
predictable orders.

A standard XML-oriented API like the DOM is entirely suitable for
group #1, but the DOM is probably overkill for group #2, which
requires a domain-specific API (of course, for small or
non-speed-critical applications, the domain-specific API could be
implemented as an adapter on top of the DOM).

That said, you still need some kind of API to get at the XML to
populate the domain-specific model.  Sometimes, the DOM will be
appropriate, but given that many models in group #2 tend to be simple
and need to be processed on busy servers, a light-weight, event-based
API like XML::Parser or SAX usually makes the most sense for that
group.

Ideally, most programmers using XML for group #2 will never see an
XML-specific API -- we should hide 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  3 15:23:50 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:11 2004
Subject: Retrieving attributes from an internal entity
Message-ID: <3.0.32.19981103071922.00ae7820@pop.intergate.bc.ca>

At 02:14 PM 11/3/98 GMT, Richard Tobin wrote:
>> <!ENTITY pct "<unit name='Percent' symbol='%'/>">
>
>This is indeed being (correctly) interpreted as a malformed parameter
>entity.  Use a character entity to refer to the percent character:

Oops.  Oh dear, Richard is right. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 16:18:02 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <002901be0716$b5121a50$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <363F2CDA.3BF7BB3D@locke.ccil.org>

Michael Kay wrote:

> Neither really works well, because "]]>" can legitimately occur in a Java
> program. For example, it is quite likely to occur in a Java program that
> generates XML.

If "]]>" is needed as a string literal or part of one, it can easily be
replaced by "]]\76" or "]]\u003E".

If it appears in program text, then "]] >" will be a sufficient
replacement.

Similar workarounds are used to avoid ETAGOs ("</") in the SCRIPT and
STYLE elements of HTML 4.0; they are necessarily language-specific.
For example, Javascript uses "<\/".

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Tue Nov  3 16:38:38 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU>
Message-ID: <363F31B6.59F3FFC7@locke.ccil.org>

Rick Jelliffe wrote:

> A CDATA marked section is not only a way to prevent delimiter recognition.
> It is also a way to declare that the characters in that section are limited
> to ones available in the direct document encoding of the originating system.

True.  However, since the standard encodings of XML include all the
characters there are (and if they don't include yours, just you
wait, 'Enry 'Iggins), that isn't as much of an issue.

> (SGML has a CDATA keyword you can use instead of content models: XML was
> felt not to need it because you could use <![CDATA[, however that perhaps
> shows the mind of the XML WG at that time, in that they were down-playing
> the need for schemas.)

CDATA elements are eeeeeevil.  They terminate at any ETAGO followed by
a name-start character, and they make it impossible to change your
mind later, if you decide you need an entity or two.  See the excellent
articles at.  They were rightly discarded from XML.

> For example, I cannot see why a smart editor could not use the CDATA section
> to cofine editing to whatever the repertoire of the character set of the
> encoding attribute of the XML header says.

IMHO, a *smart* editor would realize that a CDATA section cannot cope,
and would terminate it around the problem character.  For example,
an attempt to insert a dagger (U+2020) into a CDATA section within
an 8859-1 document would produce this:

	... ]]>&#x2020;<![CDATA[ ...

This specific case comes up when people using code page 1252 try to exploit
the non-8859-1 characters it supplies.

> In the case of editing the XML
> specification, for example, when there is a CDATA marked section being
> edited, and the editor types "<", a smart section should know not to replace
> it with "&lt;" or expect it to be a STAGO.

XED indeed has this property, although it just feeps if you attempt
to type a character that would cause "]]>" to appear in a CDATA
section, rather than splitting the section (which admittedly would
be painful to undo after a Backspace character).

> It would be nice
> if W3C allowed this, but the less that a PI can be treated (by XLL or DOM or
> SAX or whatever) as a kind of element,

The current XPointer draft allows PIs to be referred to on equal terms with
elements (except for not having a GI or attributes or sub-elements).

The DOM has a ProcessingInstruction node, though pseudo-attribute parsing
is not performed.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From lauren at sqwest.bc.ca  Tue Nov  3 16:50:11 1998
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <363F31B6.59F3FFC7@locke.ccil.org>
Message-ID: <199811031644.IAA14775@sqwest.bc.ca>

On 3 Nov 98, at 11:39, John Cowan wrote:

> The current XPointer draft allows PIs to be referred to on equal terms
> with elements (except for not having a GI or attributes or sub-elements).
> 
> The DOM has a ProcessingInstruction node, though pseudo-attribute parsing
> is not performed.

This would be a possibility, but this reading of the content of a PI 
isn't in the XML spec, so the DOM WG didn't want to add 
semantics that weren't in the spec. So we stuck to the simple 
target+data approach, at least for Level 1.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 17:07:51 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: Rick Jelliffe's message of Tue, 3 Nov 1998 22:53:27 +1100
Message-ID: <199811031707.RAA19890@cogsci.ed.ac.uk>

> (SGML has a CDATA keyword you can use instead of content models: XML was
> felt not to need it because you could use <![CDATA[, however that perhaps
> shows the mind of the XML WG at that time, in that they were down-playing
> the need for schemas.)

Surely the unanswerable argument against CDATA elements in XML was
they prevent you from parsing a document without the DTD.  Just like
optional start/end tags, and unmarked empty elements.

-- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 17:10:47 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU> <363F31B6.59F3FFC7@locke.ccil.org>
Message-ID: <363F38FE.5893FDE9@locke.ccil.org>

Blunderingly I wrote:

> See the excellent
> articles at.  

That should have been:

"at http://www.oasis-open.org/cover/topics.html#CDATA ."

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Tue Nov  3 17:12:40 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <199811031644.IAA14775@sqwest.bc.ca>
Message-ID: <363F3939.84DD643@locke.ccil.org>

Lauren Wood replied to me:

> > The DOM has a ProcessingInstruction node, though pseudo-attribute parsing
> > is not performed.
> 
> This would be a possibility, but this reading of the content of a PI
> isn't in the XML spec, so the DOM WG didn't want to add
> semantics that weren't in the spec. So we stuck to the simple
> target+data approach, at least for Level 1.

In the words of Hyman Kaplan:  "I described.  I did not condemn."

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Tue Nov  3 17:24:03 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <199811031707.RAA19890@cogsci.ed.ac.uk>
Message-ID: <000001be074e$e2ec19c0$dae887cb@NT.JELLIFFE.COM.AU>


> From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk]

> Surely the unanswerable argument against CDATA elements in XML was
> they prevent you from parsing a document without the DTD.  Just like
> optional start/end tags, and unmarked empty elements.

A good reason, but you could always say that "every CDATA element must have
an attribute xml:content-mode='CDATA'".  So not unanswerable (though neither
<![CDATA[ ]]> nor the attribute commend themselves). And not unthinkable, as
xml:lang and xml:space prove.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  3 17:32:13 1998
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun  7 17:06:11 2004
Subject: Z references (was Re: DTD,s)
Message-ID: <51ED3F5356D8D011A0B1006097C30734014E5B3D@martinique>

Since it's kind of hard to find at the site mentioned below, here is a
link to some drafts of the ISO Z standard:

http://www.cs.york.ac.uk/~ian/zstan/

The Z Reference Manual, by J.M. Spivey, is frequently referred to as the
de facto standard; lucky for us, it has gone out of print and Mr. (Ms?)
Spivey has been kind enough to make it available on the net at:

http://spivey.oriel.ox.ac.uk/~mike/zrm/

I've found "The Way of Z" very useful:
http://www.radonc.washington.edu/prostaff/jon/z-book/

-----Original Message-----
From: James Tauber [mailto:jtauber@jtauber.com]
Sent: Monday, November 02, 1998 7:31 PM
To: xml mailing list
Subject: Z references (was Re: DTD,s)


-----Original Message-----
From: Eddie Sheffield <eddie.sheffield@enterworks.com>
>BTW, did anyone ever give any references for "Z" from the recent CDATA
thread? My
>curiosity is perked, but I have a feeling searching for "Z" on Hotbot
or
Yahoo or
>wherever would prove frustrating!


Yahoo was easy. Try:

http://dir.yahoo.com/Computers_and_Internet/Programming_Languages/Z/

which leads to an excellent site:

http://www.comlab.ox.ac.uk/archive/z.html

James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Associate Researcher, Electronic Commerce Network
Curtin University of Technology, Perth, Western Australia

Maintainer of : www.xmlinfo.com,  www.xmlsoftware.com and www.schema.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  3 17:40:38 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:11 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <363F31B6.59F3FFC7@locke.ccil.org>
Message-ID: <000101be0751$1ee370c0$dae887cb@NT.JELLIFFE.COM.AU>


> From: John Cowan

> True.  However, since the standard encodings of XML include all the
> characters there are (and if they don't include yours, just you
> wait, 'Enry 'Iggins), that isn't as much of an issue.

(An optimistic view of ISO10646: there are dozens of new Han ideographs
created every day, apart from other scripts.)

The situation I am thinking of is, for example, where I am creating an XML
document which will be used, after processing by a non-XML Macintosh
application that only understands MacRoman. The CDATA marked section is the
only constraining/signalling mechanism in XML which could be applied, and it
goes without saying that it is a pretty poor one, but I don't want to say it
is useless.

If the consensus of developers is that they dont want to allow marked
sections to be used in this way, I hope that the schema people will look at
a solution for constraining strings to use certain repertoires of
characters. I believe the Balise parser and SGML/XML processing system has a
"sanity checking" option for names in markup for this kind of
repertoire-limitation purpose.

> The current XPointer draft allows PIs to be referred to on equal
> terms with elements (except for not having a GI or attributes or
> sub-elements).

> The DOM has a ProcessingInstruction node, though pseudo-attribute
> parsing is not performed.

Which is my point. By not even providing some minimal kind of token-locating
within a processing instruction for people to use if they need it, PIs are
barely useful as far as I can see.  People will always try to use what is
provided, rather than extend an API, so it is almost the kiss of death to
PIs except for the more sophisticated applications. When schemas come along
with better lexing of attribute values and PCDATA, I wonder if they will
also bother to allow scanning of the PI into tokens too.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 17:47:46 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:11 2004
Subject: XML APIs
References: <3.0.5.32.19981102121408.00c96c30@pophost.arbortext.com> <qcbtmpsygf.fsf@gelion.crc.ricoh.com> <363E08B6.2EB84756@locke.ccil.org> <qc90htssve.fsf@gelion.crc.ricoh.com> <363E2F22.4EE275D9@locke.ccil.org> <qc67cxsk4j.fsf@gelion.crc.ricoh.com>
Message-ID: <363F41DE.A57015FE@locke.ccil.org>

Stephen R. Savitzky wrote:

> I do not understand your point.  They certainly hold as far as I can tell;

Provided the tree doesn't get modified while traversing it.

> Piling additional complication into the specification in order to ensure
> that every node in the tree will continue to be visited no matter what gets
> done between calls to "toNext", which I believe is what the last spec that
> included iterators attempted to do, is WRONG, because it makes the simple
> implementation impossible and because it becomes too complicated for a
> programmer looking at the spec to guess how it's going to behave.

Well, I disagree with you.  If iterators are to be useful, they must
be robust against changes to the structure being iterated over, or
at the very least they must warn that the iterator is no longer valid,
like the new Java 1.2 enumerators.

> The API is designed to have an obvious model that looks
> like a parse tree.  Any programmer, looking at that API, will ``see'' the
> parse tree in her mind's eye and be able to make intuitive and accurate
> predictions about how it will behave.

Indeed.  But soon after learning about live node lists, this model
will have to be changed or her programs will be dreadfully erroneous.

> They will then discover that, in
> the details of the specification, the intuitive view of the DOM as the API
> for tree-structured documents is WRONG, and that a great deal of non-obvious
> machinery has to be added in order to make it work.

You betcha.
 
> I'm going to go a little further, and define ``natural model.''  The natural
> model of an interface is a class in which all attributes are represented by
> instance variables, and no other instance variables are present.

The trouble with such a "natural model" is that it's dead.  It works
perfectly for values (which have no state, i.e. are immutable),
and for "dart boards" that react to whatever's posted to (thrown at?)
them, but not for anything with any liveness.  A robot modeled by such a
"natural model" would be more like a Barbie doll: poseable, but unable
to move by itself.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Tue Nov  3 17:50:27 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:11 2004
Subject: Walking the DOM (was: XML APIs)
References: <3.0.5.32.19981102121408.00c96c30@pophost.arbortext.com> <qcbtmpsygf.fsf@gelion.crc.ricoh.com> <363E08B6.2EB84756@locke.ccil.org> <qc90htssve.fsf@gelion.crc.ricoh.com> <363E2F22.4EE275D9@locke.ccil.org> <qc67cxsk4j.fsf@gelion.crc.ricoh.com>
Message-ID: <363F4252.4F27F6EB@locke.ccil.org>

Stephen R. Savitzky wrote:

> [T]he classic algorithm for traversing a tree is:
> 
> traverse(node) {
>   visit(node);
>   if (node.firstChild != null) traverse(node.firstChild);
>   if (node.nextSibling != null) traverse(node.nextSibling);
> }

The trouble with that algorithm is that it is recursive.  It will
blow up if the tree is sufficiently deep.  Indeed, in
languages that cannot be relied on to do tail recursion, like
Java, it will blow up if the tree is merely sufficiently wide.

Furthermore, if there is any end-of-node processing to do, such as
emitting an end tag indication, then the algorithm is no longer
even partly tail recursive and will blow up on both depth and
width even in safe-tail-recursion languages.

The algorithm I use in DOMParser, therefore, is non-recursive:

   traverse(Node node) {
    Node currentNode = node;

    while (currentNode != null) {
      visit(currentNode);

      // Move down to first child
      Node nextNode = currentNode.getFirstChild();
      if (nextNode != null) {
        currentNode = nextNode;
        continue;
        }

      // No child nodes, so walk tree
      while (currentNode != null) {
        revisit(currentNode)	// do end-of-node processing, if any

        // Move to sibling if possible.
        nextNode = currentNode.getNextSibling();
        if (nextNode != null) {
          currentNode = nextNode;
          break;
          }

       // Move up
       if (currentNode = node)
	 currentNode = null;
       else
	 currentNode = currentNode.getParentNode();
       }
    }
  }

Because of the reliability of this algorithm vis-a-vis the recursive
one, I believe it should be the standard way of walking DOM trees,
and therefore it is essential that DOM implementations make the
structural access methods fast.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Tue Nov  3 17:54:58 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:11 2004
Subject: Specifying virtual fonts in XML for handling variant characters
In-Reply-To: <000001be074e$e2ec19c0$dae887cb@NT.JELLIFFE.COM.AU>
Message-ID: <000201be0752$f62b2d10$dae887cb@NT.JELLIFFE.COM.AU>

Has anyone come up with a solution for specifying virtual ("synthetic")
fonts in XML?

I need more than just saying "Latin block uses font x, greek block uses font
y", I need to be able to say "This character should use font x, that
character should use font y".

Has anyone come up with a standard way to markup which characters in the
private-use block are being used. If the Maths people are using parts of the
block, it probably would be a good idea to have some system whereby when our
documents are merged your private-use area does not overlay my private use
area.

Does anyone know what the current status of webfonts is, and what the
relation to Netscape's "Dynamic Fonts"?


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 18:07:28 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:12 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <002901be0716$b5121a50$7008e391@bra01wmhkay.bra01.icl.co.uk>
		<000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU> <13886.61181.97569.898100@localhost.localdomain>
Message-ID: <363F467F.3D832CF0@locke.ccil.org>

David Megginson wrote:

> I *do* see the usefulness in
> combination with an "xml:lang" or "mime-type" attribute, though.  An
> intelligent editor could already act on xml:lang to limit character
> selection, if such a thing were desirable.

Such an editor would have to be a durn sight more intelligent than
anything now available, because the repertoire of a language is
a sticky wicket.  In the domain of "xml:lang='en-US'", am I to be
forbidden to write "na?ve" or "co?perate"?  How about "r?sum?" or
"Qu?b?c"?

Harald Alvestrand worked for some years trying to nail down the
repertoires (r?pertoires?) of various European languages.  His
latest (1995) draft at http://www.alvestrand.no/ietf/lang-chars.txt
warns how incomplete the results still are.



-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jtauber at jtauber.com  Tue Nov  3 18:10:31 1998
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:06:12 2004
Subject: Specifying virtual fonts in XML for handling variant characters
Message-ID: <005601be0754$94abffe0$0300000a@othniel.cygnus.uwa.edu.au>

-----Original Message-----
From: Rick Jelliffe <ricko@allette.com.au>

>Has anyone come up with a solution for specifying virtual ("synthetic")
>fonts in XML?
>
>I need more than just saying "Latin block uses font x, greek block uses
font
>y", I need to be able to say "This character should use font x, that
>character should use font y".


I actually need this for FOP[1]. FOP is taking in Unicode but outputting PDF
using Type 1 fonts with AdobeStandardEncoding.

James

[1] http://www.jtauber.com/fop/


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Tue Nov  3 18:16:56 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:12 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU>
Message-ID: <363F0962.C0F19885@technologist.com>

Rick Jelliffe wrote:
> 
> For example, I cannot see why a smart editor could not use the CDATA section
> to cofine editing to whatever the repertoire of the character set of the
> encoding attribute of the XML header says. 

Because it would be redundant. If the XML header says what characters are
available then the editor can directly enforce that constraint.

Overloading markup in this way is, in my opinion, a bad idea. It can do
nothing but bring harm in the long term because no two applications will
agree on the overloaded semantics and thus no two applications will treat
the data in the same way.

> The <![JAVA[ ]]> idea was not that JAVA would be a "CDATA marked section",
> but an "RCDATA marked section", which means that special character
> references and entity references would be allowed. 

This would eliminate the most interesting thing about CDATA sections:
character suppression. Making <![JAVA[ RCDATA is going in the wrong
direction. Rather it should be a CDATA-on-steriods that even ignores CDEnd
("]]>") and only looks for something like ]JAVA]> to end the section.

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

"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Tue Nov  3 18:20:44 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:12 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000101be0751$1ee370c0$dae887cb@NT.JELLIFFE.COM.AU>
Message-ID: <363F4951.E05D1C5D@locke.ccil.org>

Rick Jelliffe wrote:

> (An optimistic view of ISO10646: there are dozens of new Han ideographs
> created every day, apart from other scripts.)

True but irrelevant, since no specifiable character set can hold these.

> I hope that the schema people will look at
> a solution for constraining strings to use certain repertoires of
> characters.

And I hope that they allow no such thing, except perhaps as a fall-out
from some regex or other local syntax mechanism.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Tue Nov  3 18:24:39 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:12 2004
Subject: Apologies for misdirected mail
Message-ID: <363F49FD.9285BD6D@locke.ccil.org>

The two messages "Re: XML APIs" and "Walking the DOM" from me
should have gone to the DOM mailing list (where they now have been
sent) rather than to XML-DEV.

My apologies to those who do not care about them DOM, and especially
to those who will now see the messages twice.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Tue Nov  3 18:29:15 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:12 2004
Subject: Walking the DOM (was: XML APIs)
Message-ID: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca>

At 12:50 PM 11/3/98 -0500, John Cowan wrote:
>Stephen R. Savitzky wrote:
>
>> [T]he classic algorithm for traversing a tree is:
>> traverse(node) {
...
>> }
>
>The trouble with that algorithm is that it is recursive.  It will
>blow up if the tree is sufficiently deep.  Indeed, in
>languages that cannot be relied on to do tail recursion, like
>Java, it will blow up if the tree is merely sufficiently wide.

Wouldn't the effects of recursion will be lost in the static,
compared to the effects of loading the doc into memory to facilitate
tree processing?  Even if you are doing some persistent-ancillary-
info trick to do a virtual tree, in my experience for very large
docs you really have to wrangle memory carefully.  It seems
really counter-intuitive that the stack & local variables overhead
caused by recursion is going to get you before one of these
other things.   Unless of course you recurse in some huge
sloppy badly-written routine with lots of local junk.

BTW, what languages can be relied on to do tail recursion?

Also, shorter algorithms are better. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 18:32:43 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:12 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <000001be0720$918764f0$aee887cb@NT.JELLIFFE.COM.AU> <363F0962.C0F19885@technologist.com>
Message-ID: <363F4BD1.16B2DC78@locke.ccil.org>

Paul Prescod replied to Rick Jelliffe:

> > The <![JAVA[ ]]> idea was not that JAVA would be a "CDATA marked section",
> > but an "RCDATA marked section", which means that special character
> > references and entity references would be allowed.

I missed this before.  Java doesn't need character references, for
which it has its own syntax, and entity references would IMHO cause
more confusion then they are worth, since & and < have well-known
Java semantics utterly distinct from their SGML (reference) semantics.
 
> This would eliminate the most interesting thing about CDATA sections:
> character suppression. Making <![JAVA[ RCDATA is going in the wrong
> direction. Rather it should be a CDATA-on-steriods that even ignores CDEnd
> ("]]>") and only looks for something like ]JAVA]> to end the section.

Doesn't help, because the recursive problem remains vivid when Java
programs generate SGML.  Keep CDEnd and use "]]\76" inside Java
strings, "]] >" in ordinary Java source.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From drabin at Adobe.COM  Tue Nov  3 19:07:48 1998
From: drabin at Adobe.COM (Dan Rabin)
Date: Mon Jun  7 17:06:12 2004
Subject: Walking the DOM (was: XML APIs)
In-Reply-To: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981103110605.00f35670@mail-345>

At 10:27 AM 11/3/98 -0800, Tim Bray wrote:
>BTW, what languages can be relied on to do tail recursion?

Scheme can be so relied on (for sure), and Standard ML too (I think).

  -- Dan Rabin


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Tue Nov  3 19:10:27 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:12 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <363F4951.E05D1C5D@locke.ccil.org>
Message-ID: <000301be075d$a1376e30$dae887cb@NT.JELLIFFE.COM.AU>



> From: John Cowan

> Rick Jelliffe wrote:
>
> > (An optimistic view of ISO10646: there are dozens of new Han ideographs
> > created every day, apart from other scripts.)
>
> True but irrelevant, since no specifiable character set can hold these.

Not so. The additions are use composed of standard radicals and
combinations. There are various projects around (such as C.C.Hsieh in
Taiwan) to figure out encodings to "spell" Han ideographs by component
radicals. This would allow any number of characters and even variant forms.
But this is not in ISO 10646 yet.

I guess the point is that John thinks that if an XML system can produce
characters which a recipient system cannot process, because it does not use
ISO 10646, that is not something that CDATA sections should be used to
address. I think his reasons are that he cannot see it in the spec. Dave M
thinks that xml:lang is appropriate. My point about CDATA elements was that
there is no standard mechanism to lock CDATA marked sections. I think a lot
of people now think that any non-ISO10646 system is for losers anyway
(except for whatever character set they use, probably).

> .. the repertoire of a language is
> a sticky wicket.  In the domain of "xml:lang='en-US'", am I to be
> forbidden to write "na?ve" or "co?perate"?  How about "r?sum?" or
> "Qu?b?c"?

The primary purpose of xml:lang, as far as I am concerned, should be to
convey the information lost by ISO 10646 unification: where the Japanese and
Chinese glyphs (or Polish and Russian) for a unified character differ, then
I think transcoding and unifying the characters into ISO 10646 can lose
information unless the xml:lang attribute is set. After that, xml:lang can
be used to label text for the purposes of variant character selection, and
after that for marking up the natural language.

But I am not trying to fix the repertoire of a language (TEI WSD can declare
it, though). I am just thinking about how to constrain XML documents so that
they will not contain characters which will break non-ISO10646 target
systems.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov  3 19:13:37 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:12 2004
Subject: Walking the DOM (was: XML APIs)
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca>
Message-ID: <363F55AB.AEA4EB19@locke.ccil.org>

Tim Bray wrote:

> Wouldn't the effects of recursion will be lost in the static,
> compared to the effects of loading the doc into memory to facilitate
> tree processing?

That produces slow processing, not a hard failure (unless indeed there
is simply too much document for even virtual memory).  Java, and
all other HLLs I know of, provide no way to recover from
stack overflow, short of starting the app all over again with
a command-line switch for a bigger stack.

A general-purpose routine ought not to generate a preventable
hard failure no matter what the document looks like, IMHO.

> BTW, what languages can be relied on to do tail recursion?

Scheme and ML and their descendants.  The Scheme version of
Stephen's algorithm will detect the tail recursion, and will
be recursive down the tree and iterative across it.

Indeed, Scheme *has* no (primitive) way to do iteration except
with tail recursion (there are macros that syntactically sugar
this, if you want).  As a result, Scheme compilers can concentrate
on making the very few constructs they have to understand
(function call, function closure, assignment, IF) very very
efficient.
 
> Also, shorter algorithms are better. -Tim

But constant-space algorithms are better too.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Tue Nov  3 20:40:43 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:12 2004
Subject: Unicode, xml:lang, and variant glyphs
References: <000301be075d$a1376e30$dae887cb@NT.JELLIFFE.COM.AU>
Message-ID: <363F657F.5D2E1B43@locke.ccil.org>

Rick Jelliffe wrote:

> Not so. The additions are use composed of standard radicals and
> combinations. There are various projects around (such as C.C.Hsieh in
> Taiwan) to figure out encodings to "spell" Han ideographs by component
> radicals. 

I'm glad to hear about this; I find the IRG archives utterly
impenetrable.

> I guess the point is that John thinks that if an XML system can produce
> characters which a recipient system cannot process, because it does not use
> ISO 10646, that is not something that CDATA sections should be used to
> address. I think his reasons are that he cannot see it in the spec. [...]
> I think a lot
> of people now think that any non-ISO10646 system is for losers anyway
> (except for whatever character set they use, probably).

Well, actually I would say the latter rationale has more effect on me
than the former, if I must choose either.  It just seemed to me that
using CDATA sections to constrain the behavior of editors was not
particularly user-friendly; if the user wants a character, let her
have it, using a character reference if possible.

In general, transcoding XML documents involves inserting NCRs as needed,
unless the target is UTF-8 or UTF-16.

> The primary purpose of xml:lang, as far as I am concerned, should be to
> convey the information lost by ISO 10646 unification: where the Japanese and
> Chinese glyphs

Actually, the problem isn't that clearcut.  As John Jenkins posted
to the Unicode list last year:

# FACT.  It is true that some Unihan characters are typically written 
# differently within the Japanese, Taiwanese, Korean, and Mainland Chinese 
# typographic traditions.  
# 
# FACT.  These differences of writing style are within the general range of 
# allowable differences within each typographic tradition.  
# 
# E.g., the official "Taiwanese" glyph for U+8349 ("grass") per ISO/IEC 
# 10646 uses four strokes for the "grass" radical, whereas the PRC, 
# Japanese, and Korean glyphs use three.  As it happens, Apple's LiSung 
# Light font for Big Five (which follows the "Taiwanese" typographic 
# tradition) uses three strokes.  
# 
# (This is easily confirmed by accessing 
# http://www.unicode.org/unihan/unihan.acgi$8349.)  
# 
# FACT.  Japanese users prefer to see Japanese text written with "Japanese" 
# glyphs.  
# 
# FACT.  It is also acceptable to Japanese users to see Chinese text 
# written with "Japanese" glyphs.  
# 
# E.g., I just borrowed from Lee Collins a standard Japanese dictionary 
# which quotes Chinese authors (e.g., Mencius) to show how a character is 
# used.  When doing so, they use "Japanese" glyphs, not Chinese ones. 
# 
# In particular, it is acceptable within Japanese typography for a small 
# stretch of Chinese quoted in a predominantly Japanese text to be written 
# with "Japanese" glyphs.  
# 
# FACT.  Han unification allows for the possibility that a Japanese user 
# might be required to use a Chinese font to display some Japanese text 
# (e.g., if it uses a rare kanji).  
# 
# FACT.  Ditto for JIS or an ISO 2022-based solution.  
# 
# FACT.  Unicode doesn't include all the characters in actual use in Japan 
# today, particularly for personal names.  
# 
# FACT.  Neither does JIS or an ISO 2022-based solution.  There are vendor 
# sets which include many of these characters, and Unicode is working with 
# the IRG and East Asian national bodies to add them.
  
> (or Polish and Russian)

How's that again?

Polish uses Latin, Russian uses Cyrillic!  What could possibly
count as a unification between these two??  *Nobody* thinks that
LATIN LETTER A and CYRILLIC LETTER A should be unified....

> for a unified character differ, then
> I think transcoding and unifying the characters into ISO 10646 can lose
> information unless the xml:lang attribute is set.

It doesn't lose information about meaning.  It may make characters
harder to read, but the distinction is one of typographic tradition,
not language, and can cross languages.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jcw at equi4.com  Tue Nov  3 21:40:30 1998
From: jcw at equi4.com (Jean-Claude Wippler)
Date: Mon Jun  7 17:06:12 2004
Subject: [Fwd: Walking the DOM (was: XML APIs)]
References: <363F54B8.6268F15@totten.com>
Message-ID: <363F7816.DF478026@equi4.com>

John Cowan wrote:

> Stephen R. Savitzky wrote:
> 
> > [T]he classic algorithm for traversing a tree is:
> >
> > traverse(node) {
> >   visit(node);
> >   if (node.firstChild != null) traverse(node.firstChild);
> >   if (node.nextSibling != null) traverse(node.nextSibling);
> > }
> 
> The trouble with that algorithm is that it is recursive.  It will
> blow up if the tree is sufficiently deep.  Indeed, in
> languages that cannot be relied on to do tail recursion, like
> Java, it will blow up if the tree is merely sufficiently wide.
> 
> Furthermore, if there is any end-of-node processing to do, such as
> emitting an end tag indication, then the algorithm is no longer
> even partly tail recursive and will blow up on both depth and
> width even in safe-tail-recursion languages.
> 
> The algorithm I use in DOMParser, therefore, is non-recursive:
[...]

The way I load an XML document into MetaKit, it uses an explicit stack
with exactly one "int" per level.  I think you'll agree that this amount
of "stack" use makes the approach suitable for any document (once I add
some tests - this is just an experiment for now).  Source code is at:
	http://www.equi4.com/metakit/xml/mk4xml.cpp

After that, you end up with an on-demand loaded document, which is
indexable so there is no scanning at all when accessing this data. 
Every child node is in an indexable "subview".  And when you *do* need
traversal, you can again use the same one-int-per-level stack approach.

This works equally well in the case of end-node processing, BTW.

> Because of the reliability of this algorithm vis-a-vis the recursive
> one, I believe it should be the standard way of walking DOM trees,
> and therefore it is essential that DOM implementations make the
> structural access methods fast.

By reliability, do you mean "not blowing up its stack"?

As you can see, there are more ways than one to skin this cat.  It seems
to me that standardizing in the way you propose will prevent the use of
other techniques - such as storing XML as a MetaKit datafile and using
explicit recursion.

-- Jean-Claude

________________________________________________________________________
Jean-Claude Wippler    MetaKit home page - http://www.equi4.com/metakit/
Equi4 Software         "Portable database software for a changing world"

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jcw at equi4.com  Tue Nov  3 21:41:24 1998
From: jcw at equi4.com (Jean-Claude Wippler)
Date: Mon Jun  7 17:06:12 2004
Subject: [Fwd: Walking the DOM (was: XML APIs)]
References: <363F54B8.6268F15@totten.com>
Message-ID: <363F7824.EE88DDDB@equi4.com>

John Cowan wrote:

> Stephen R. Savitzky wrote:
> 
> > [T]he classic algorithm for traversing a tree is:
> >
> > traverse(node) {
> >   visit(node);
> >   if (node.firstChild != null) traverse(node.firstChild);
> >   if (node.nextSibling != null) traverse(node.nextSibling);
> > }
> 
> The trouble with that algorithm is that it is recursive.  It will
> blow up if the tree is sufficiently deep.  Indeed, in
> languages that cannot be relied on to do tail recursion, like
> Java, it will blow up if the tree is merely sufficiently wide.
> 
> Furthermore, if there is any end-of-node processing to do, such as
> emitting an end tag indication, then the algorithm is no longer
> even partly tail recursive and will blow up on both depth and
> width even in safe-tail-recursion languages.
> 
> The algorithm I use in DOMParser, therefore, is non-recursive:
[...]

The way I load an XML document into MetaKit, it uses an explicit stack
with exactly one "int" per level.  I think you'll agree that this amount
of "stack" use makes the approach suitable for any document (once I add
some tests - this is just an experiment for now).  Source code is at:
	http://www.equi4.com/metakit/xml/mk4xml.cpp

After that, you end up with an on-demand loaded document, which is
indexable so there is no scanning at all when accessing this data. 
Every child node is in an indexable "subview".  And when you *do* need
traversal, you can again use the same one-int-per-level stack approach.

This works equally well in the case of end-node processing, BTW.

> Because of the reliability of this algorithm vis-a-vis the recursive
> one, I believe it should be the standard way of walking DOM trees,
> and therefore it is essential that DOM implementations make the
> structural access methods fast.

By reliability, do you mean "not blowing up its stack"?

As you can see, there are more ways than one to skin this cat.  It seems
to me that standardizing in the way you propose will prevent the use of
other techniques - such as storing XML as a MetaKit datafile and using
explicit recursion.

-- Jean-Claude

________________________________________________________________________
Jean-Claude Wippler    MetaKit home page - http://www.equi4.com/metakit/
Equi4 Software         "Portable database software for a changing world"

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Jon.Bosak at eng.Sun.COM  Tue Nov  3 22:46:59 1998
From: Jon.Bosak at eng.Sun.COM (Jon Bosak)
Date: Mon Jun  7 17:06:12 2004
Subject: DTD,s
Message-ID: <199811032243.OAA23029@boethius.eng.sun.com>

[Frank Boumphrey:]

| Does any one know of a site where XML dtd's are available for general
| use?

OASIS (http://www.oasis-open.org) is slowly gearing up to provide a
DTD registry.  This will no doubt be discussed at the OASIS meeting in
Chicago November 15.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  3 23:34:00 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:12 2004
Subject: Last Call issued on initial stylesheet linking draft
Message-ID: <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>

Posting this on behalf the Syntax WG; xml-dev is obviously
highly qualified to provide feedback.

Cover letter is from Syntax WG co-chair Joel Nava
===================================================================

The XML Syntax Working Group of the W3C is issuing a "Last Call" 
for comments on the specification "Associating stylesheets with 
XML documents - version 1.0"

      http://www.w3.org/TR/WD-xml-stylesheet

Please review the document and send any comments you have
to jjc@jclark.com, tbray@textuality.com, jnava@adobe.com.

Comments are due by Friday Nov. 20th.

To save bandwidth, I am including some rationale for the
specific syntax we are using in this specification.

As you will notice, the Working Group has chosen to use a special 
processing instruction, or PI, to link an XML document to stylesheets. 
Some wonder whether an element or attribute based solution somewhere 
along the lines of XLink or the XML Namespace mechanism would be more
appropriate.

The reasons for our choice are 3-fold:

First, for the most part the working group feels that this syntax 
is the best for the problem. Many argue that this is the proper use 
for a PI, because it keeps this information out of the document tree.

Second, timing is an issue. The mechanism that we have produced 
is very similar to the HTML link element, and was agreed upon 
many months prior to the formation of this WG. The XML Style 
Sheet Linking Specification was a partially completed work item 
from the old XML WG. In the intervening time between the end of 
that group and the beginning of this group the time to make an 
impact on the next release from the browser vendors was slipping 
away.  We have tried to move quickly to complete this specification
in order to have an impact on what gets implemented. Both Microsoft 
and Netscape have agreed on this syntax, and as far as we can guess 
will be shipping products based on it in the near future.

The third part of this is the fact that time and resources have
already been put aside to produce a Version 2 of this specification.
"Associating stylesheets with XML documents - version 2.0" will add
other mechanisms for linking style to XML document; see
 
    http://www.w3.org/XML/Activity.html#future

--
Joel A. Nava                  (408)536-6209
Adobe Systems, Inc.         jnava@adobe.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Tue Nov  3 23:42:49 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:12 2004
Subject: Last call - correction
Message-ID: <3.0.32.19981103154228.009fc660@pop.intergate.bc.ca>

[oops - date error in previous posting]

>> Comments are due by Friday Nov. 20th.

should read

Comments are due by Tuesday Nov. 17th

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


From papresco at technologist.com  Wed Nov  4 00:42:40 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:12 2004
Subject: Walking the DOM (was: XML APIs)
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca>
Message-ID: <363F9E39.D978D55F@technologist.com>

Tim Bray wrote:
> 
> >The trouble with that algorithm is that it is recursive.  It will
> >blow up if the tree is sufficiently deep.  Indeed, in
> >languages that cannot be relied on to do tail recursion, like
> >Java, it will blow up if the tree is merely sufficiently wide.
> 
> Wouldn't the effects of recursion will be lost in the static,
> compared to the effects of loading the doc into memory to facilitate
> tree processing?  Even if you are doing some persistent-ancillary-
> info trick to do a virtual tree, in my experience for very large
> docs you really have to wrangle memory carefully.  

But the persistent ancillary-info trick (i.e. "object database") keeps
only the data it needs to in memory. If it requires lots of swapping, that
slows things down, but the algorithm works nevertheless. If you blow your
stack, you blow your stack, and there is no database in the world that
will help you.

Depending on the algorithm, walking an object database tree for a really
huge file may be faster than parsing it and event-processing it. It
depends on how many nodes you are actually processing, and how much
ancillary info you must keep around to solve the problem you need to
solve.

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

"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From phani at www.hsc.wvu.edu  Wed Nov  4 02:42:01 1998
From: phani at www.hsc.wvu.edu (Phani Adabala)
Date: Mon Jun  7 17:06:12 2004
Subject: xml parser
Message-ID: <Pine.BSF.3.91.981103213843.14937B-100000@www.hsc.wvu.edu>


1.To develop a search engine for xml documents, can we use the xml parser 
already developed by microsoft and others or do we need to build our own 
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Wed Nov  4 09:18:38 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:13 2004
Subject: CDATA by any other name... (was The raw and the cooked)
Message-ID: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de>

John Cowan wrote:

> Rick Jelliffe wrote:
>
> > I hope that the schema people will look at
> > a solution for constraining strings to use certain repertoires of
> > characters.
> 
> And I hope that they allow no such thing, except perhaps as a fall-out
> from some regex or other local syntax mechanism.

Why not?  This would be very useful for constraining what can be put into a database, many (most?) of which do not support Unicode.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Wed Nov  4 09:43:40 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:13 2004
Subject: Last Call issued on initial stylesheet linking draft
Message-ID: <01BE07DF.52B752C0@grappa.ito.tu-darmstadt.de>

The second S in StylesheetPI and both S's in PseudoAtt should be optional.  Even the examples don't include them.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  4 09:45:35 1998
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:06:13 2004
Subject: Walking the DOM (was: XML APIs)
In-Reply-To: <363F9E39.D978D55F@technologist.com>
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca>
Message-ID: <3.0.6.32.19981104093649.0095e800@gpo.iol.ie>

[Paul Prescod]
>But the persistent ancillary-info trick (i.e. "object database") keeps
>only the data it needs to in memory. If it requires lots of swapping, that
>slows things down, but the algorithm works nevertheless. If you blow your
>stack, you blow your stack, and there is no database in the world that
>will help you.
>
>Depending on the algorithm, walking an object database tree for a really
>huge file may be faster than parsing it and event-processing it. It
>depends on how many nodes you are actually processing, and how much
>ancillary info you must keep around to solve the problem you need to
>solve.
>
In my experience, there is a strong "principle of locality" in
XML/SGML processing. I find I can get by quite happily with
mini-tree structures harvested at suitable points from
a larger document processed event-style. In my
Python toolkit for SGML/XML processing I added support
for sparse tree building some time ago and I find myself
using it more and more.

This is certainly far easier to do that implement virtual
tree access with swapping to disk etc. You don't need
no object database either:-)


</Sean>

                http://www.python.org
The "Swiss Army Laser Beam" of programming languages


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ht at cogsci.ed.ac.uk  Wed Nov  4 09:58:02 1998
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:06:13 2004
Subject: Hybrid event/tree interfaces (was: Walking the DOM (was: XML APIs))
In-Reply-To: Sean Mc Grath's message of "Wed, 04 Nov 1998 09:36:49 +0000"
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca> <3.0.6.32.19981104093649.0095e800@gpo.iol.ie>
Message-ID: <f5b90hreq5c.fsf_-_@cogsci.ed.ac.uk>

Sean Mc Grath <digitome@iol.ie> writes:

> In my experience, there is a strong "principle of locality" in
> XML/SGML processing. I find I can get by quite happily with
> mini-tree structures harvested at suitable points from
> a larger document processed event-style. In my
> Python toolkit for SGML/XML processing I added support
> for sparse tree building some time ago and I find myself
> using it more and more.
> 
> This is certainly far easier to do that implement virtual
> tree access with swapping to disk etc. You don't need
> no object database either:-)

Our experience is very much in agreement with this.  We have been
using an API [1] which allows you to switch from event to
tree(-fragment) view for the last few years, and it is a very
productive way to go.  You can think of it as allowing you to loop
over nodes in a document which match a query in a restricted query
language, restricted in that you can only query properties
(e.g. tag name, attribute values) of candidate nodes and their
ancestors:  no descendents or siblings.  If you like what you see,
THEN you can ask for the whole subtree rooted in that node, and do
whatever you like with it.

It should be clear that a simple implementation of this is possible,
which only needs to keep a stack of current ancestor start-tags.  The
result is no upper bound on document size:  we regularly push 2GB of
XML through a chain of filters implemented in this way.

ht

[1] http://www.ltg.ed.ac.uk/software/xml/
-- 
  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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Wed Nov  4 11:00:01 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:13 2004
Subject: xml parser
Message-ID: <004701be07e1$9290ed00$7008e391@bra01wmhkay.bra01.icl.co.uk>

>
>1.To develop a search engine for xml documents, can we use the xml parser
>already developed by microsoft and others or do we need to build our own
>parser?

My immediate answer to this is yes, all the information you need for a
search engine is available via the SAX or DOM interface offered by many
parsers.

This is certainly true for the indexing phase; for displaying hit documents
I can think of some requirements that a standard parser might not meet, such
as displaying the text around a search term without parsing the whole
document. So it depends on your detailed design. But in any case many XML
parsers are available with source code so you shouldn't need to write a new
one from scratch.

Of course you don't need to build your own search engine either, all you
need to do is write an XML filter for an existing search engine. I'm
surprised no-one seems to have done this yet.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Wed Nov  4 11:14:03 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:13 2004
Subject: xml parser
Message-ID: <01BE07EB.ED7FB070@GRAPPA>

Phani Adabala wrote:

> 1.To develop a search engine for xml documents, can we use the xml parser 
> already developed by microsoft and others or do we need to build our own 
> parser?

You definitely don't need to write your own parser -- there are plenty available, including Microsoft's.  See, for example:

http://www.xmlsoftware.com/parsers/
http://www.oasis-open.org/cover/xml.html#xmlSoftware

It would also be a good idea to write your software in a parser-independent way, using SAX (http://www.megginson.com/SAX/) or DOM (http://www.w3.org/TR/REC-DOM-Level-1/).  The former is an event-driven interface, the latter is a tree interface.

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dip.co.uk  Wed Nov  4 11:35:55 1998
From: rja at dip.co.uk (Richard James Anderson)
Date: Mon Jun  7 17:06:13 2004
Subject: xml parser
Message-ID: <000101be07e7$5c3e2910$c5010180@p197>

Hi,

For those who are interested, I've posted an early version of my ActiveX SAX
control up on my website ( URL below ).

The control still has a long way to go, but it can parse most files that do
not contain references to external entities.

The download includes a sample VB6 app for reading and processing XML files.
It just loads the XML file into a tree control, and shows the SAX events in
a list control.   Of course, the control can be used to anything that
supports COM automation controllers.

Enjoy,

Richard.

RJA@DIP.CO.UK
http://www.arpsolutions.demon.co.uk

*** The text contained within this message is of a personal nature that does
not reflect the development of opinions of data interchange plc unless
specifically stated ***


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Wed Nov  4 11:49:30 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:13 2004
Subject: CDATA by any other name... (was The raw and the cooked)
In-Reply-To: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de>
References: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de>
Message-ID: <13888.15941.518550.194555@localhost.localdomain>

Ronald Bourret writes:

 > Why not?  This would be very useful for constraining what can be
 > put into a database, many (most?) of which do not support Unicode.

There are three, much better choices for specific problems like this:

1. Have the application throw an error if an out-of-range character
   appears.

2. Convert the text to UTF-8 before storing it in the database (UTF-8
   and ASCII are identical up to 0x7f)

3. Escape non-ASCII characters with character references before
   storing the text in the database.

As I mentioned before, it's always better to be explicit about this
kind of thing -- syntactic subtlety is a bad thing.


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


From papresco at technologist.com  Wed Nov  4 14:03:02 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:13 2004
Subject: Walking the DOM (was: XML APIs)
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca> <3.0.6.32.19981104093649.0095e800@gpo.iol.ie>
Message-ID: <364059E7.4E2067AB@technologist.com>

Sean Mc Grath wrote:
> 
> In my experience, there is a strong "principle of locality" in
> XML/SGML processing. I find I can get by quite happily with
> mini-tree structures harvested at suitable points from
> a larger document processed event-style. In my
> Python toolkit for SGML/XML processing I added support
> for sparse tree building some time ago and I find myself
> using it more and more.

As long as you "get by", more power to you. But what happens when you hit
a document where the first paragraph makes a cross reference to the last
paragraph and the last paragraph makes a reference to somewhere in the
middle? You can hack around it (after all, some people get away with using
Omnimark!), but you will be hacking. You could also hack around local tree
access. Given the choice of hacking around one or the other, I would
rather hack around local references, because those are more predictable.

> This is certainly far easier to do that implement virtual
> tree access with swapping to disk etc. You don't need
> no object database either:-)

That's true, but it doesn't scale to the full generality of problems. As
long as you can get away with it, do so, but I know that I have problems
that require the Full Monty.

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

"I always wanted to be somebody, but I should have been more
specific." --Lily Tomlin

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Wed Nov  4 14:54:52 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:13 2004
Subject: Walking the DOM (was: XML APIs)
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca> <363F9E39.D978D55F@technologist.com>
Message-ID: <36406AF7.4C8A6CD6@locke.ccil.org>

Paul Prescod wrote:

> If it requires lots of swapping, that
> slows things down, but the algorithm works nevertheless. If you blow your
> stack, you blow your stack, and there is no database in the world that
> will help you.

What he said.

Hence the desirability of a non-stack-based algorithm.
 
-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From msabin at cromwellmedia.co.uk  Wed Nov  4 15:17:37 1998
From: msabin at cromwellmedia.co.uk (Miles Sabin)
Date: Mon Jun  7 17:06:13 2004
Subject: Interface name quandry ...
Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-981104151435Z-6155@odin.cromwellmedia.co.uk>

Apologies in advance if this is a bit off topic,
and apologies to those who get multiple copies.

I'm working on a number of Java APIs which operate
on documents and their DOM representations relying
on only the intersection of the properties of XML
and HTML, and I've been racking my brains for a
good name that covers both HTML and XML, but isn't
as general as SGML.

Has anybody got any suggestions?

Cheers,


Miles

-- 
Miles Sabin                          Cromwell Media
Internet Systems Architect           5/6 Glenthorne Mews
+44 (0)181 410 2230                  London, W6 0LJ
msabin@cromwellmedia.co.uk           England



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Wed Nov  4 15:26:38 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:13 2004
Subject: Last Call issued on initial stylesheet linking draft
References: <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <36407254.FF6816DD@locke.ccil.org>

Joel Nava wrote:

> To save bandwidth, I am including some rationale for the
> specific syntax we are using in this specification.

I believe that a lightly edited version of this rationale should
be included as an (informative) appendix to the recommendation.
Otherwise I believe people will see the rec as unmotivated
and will ignore it.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sroth at radsys.com  Wed Nov  4 15:28:53 1998
From: sroth at radsys.com (Roth, Scott)
Date: Mon Jun  7 17:06:13 2004
Subject: Text file to XML??
Message-ID: <5FAFB2A5D7B2D111ACEA0060972027CE186366@RADSYS_EXCH>

Help....???

I am working on a way to take delimited text file that has data in it and
break that up so that I can make files that hold xml data within it.  The
text file holds metadata already that points to files and holds certain key
information.  What I want to do is take that data and have it put the proper
xml tags in where the fields are and then take that data and put it also
into the file.  Then I want to add the proper HTML. Does this make sense???

Please help me out I want to know if anybody out there has done this already
so I don't have to reinvent the wheel.  And if anyone has any helpful hints
please let me know.  

Thanks,

Scott Roth

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Wed Nov  4 15:49:19 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:13 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de>
Message-ID: <364077B9.AB1AA3A6@locke.ccil.org>

Ronald Bourret wrote:

> Why not?  This would be very useful for constraining what can be put
> into a database, many (most?) of which do not support Unicode.

Because I thought XML (and Unicode) were in the business of enabling,
not constraining.  Lack of support for anything but Western Europe
is an unfortunate misfeature to be worked around.  Perhaps the
routines that will later read from the database (not in XML, I assume)
can be taught to understand HCRs.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Wed Nov  4 16:00:55 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:13 2004
Subject: Interface name quandry ...
References: <c=US%a=_%p=Cromwell_Media%l=ODIN-981104151435Z-6155@odin.cromwellmedia.co.uk>
Message-ID: <36407A63.DF462A3F@locke.ccil.org>

Miles Sabin wrote:

> I've been racking my brains for a
> good name that covers both HTML and XML, but isn't
> as general as SGML.
> 
> Has anybody got any suggestions?

XHTML has been used on this list, and I think is well understood.
Some people have also used the term "HTML 5.0" :-)

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tug at wilson.co.uk  Wed Nov  4 16:15:29 1998
From: tug at wilson.co.uk (John Wilson)
Date: Mon Jun  7 17:06:14 2004
Subject: Parsing XML for direct use by programs
Message-ID: <020d01be080e$3ebfe3c0$010a0a0a@bach.wilson.co.uk>

Programs that consume XML generally have to use a two stage process:

1/ Parse the XML
2/ Create new objects to represent the data in the document

(Here I'm thinking of things like EDI applications rather than of XML
browsers. In these cases I have elements which represent dates, amounts of
money, par number, etc. and I need to turn them into the appropriate
internal data structures before my program can process them.)

I have lots of support for step 1 but little or no support for step 2 (I'll
address Bill la Forge's Coins system latter)

What I think I would find helpful is a system which would let me describe
how an XML document which corresponds to a given DTD be converted into an
instances of a particular objects in my particular programming language. Of,
course I'd like to describe this in XML!

To take a concrete example:

There are several ways of expressing a date in various DTDs in use now.
In my Java program I want to deal with instances of java.util.Date.
I don't want to encumber my program with all the hand crafted tedious detail
of turning the XML element into an instance of java.util.Date by hand.

I do want a standard package that reads a DTD an DTD->Java Object mapping
description and an XML document and spits out the object tree that is
understood by my program, not a DOM tree.


Now, as I understand it, Coins can sort of do this but the designer of the
DTD has really to take Coins into account at the beginning. This isn't what
I want to do at all. I want the same DTD to be combined with different
mapping descriptions to produce different object trees and I want different
DTDs to be combined with different mapping descriptions to provide the same
object tree.

Is anybody working on this?
Is it feasible?
Is it useful?

John Wilson
The Wilson Partnership
5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
+44 1296 641072, +44 976 611010(mobile), +44 1296 641874(fax)
Mailto: tug@wilson.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rhanson at blast.net  Wed Nov  4 16:20:05 1998
From: rhanson at blast.net (Robert Hanson)
Date: Mon Jun  7 17:06:14 2004
Subject: xml parser
Message-ID: <000e01be080e$d8728220$12b919ce@Bertha>

I downloaded your control, and have some questions...

1. Why can't I get it to work?

Ok, that was only one question, but a serious one.

I'm am trying to add Perl to your list of "Tested with", but ran into some
problems.  Below is the code I used:

1.  use Win32::OLE;
2.
3.  $parser = Win32::OLE->new('SAX.SAXParser') or die $!;
4.  $parser->parseFile('c:\winn95\desktop\test.xml') or die $!;
5.  undef $parser;
6.
7.  sub characters
8.   {
9.   my ($sCharacter, $iLength) = @_;
10.  print "$sCharacter\n\n";
11.  }

It seems to be able to create the SAX object in line 3, but dies on line 4
with the parseFile method.  Is there anyway to
get an error from the parser to see what the problem is... maybe a
getLastError method?  If I get a chance, I may also try it out with
PerlScript (or VBScript) in ASP later this week.

...If you (or anyone else) have any other ideas on getting this to work,
please let me know.

Many thanks,
    Robert


-----Original Message-----
From: Richard James Anderson <rja@dip.co.uk>
To: XMLDEV <xml-dev@ic.ac.uk>
Date: Wednesday, November 04, 1998 6:36 AM
Subject: RE: xml parser


>Hi,
>
>For those who are interested, I've posted an early version of my ActiveX
SAX
>control up on my website ( URL below ).
>
>The control still has a long way to go, but it can parse most files that do
>not contain references to external entities.
>
>The download includes a sample VB6 app for reading and processing XML
files.
>It just loads the XML file into a tree control, and shows the SAX events in
>a list control.   Of course, the control can be used to anything that
>supports COM automation controllers.
>
>Enjoy,
>
>Richard.
>
>RJA@DIP.CO.UK
>http://www.arpsolutions.demon.co.uk
>
>*** The text contained within this message is of a personal nature that
does
>not reflect the development of opinions of data interchange plc unless
>specifically stated ***
>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Wed Nov  4 16:23:10 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:14 2004
Subject: xml parser
Message-ID: <3.0.32.19981104081951.00b61b10@pop.intergate.bc.ca>

At 10:55 AM 11/4/98 -0000, Michael Kay wrote:
>My immediate answer to this is yes, all the information you need for a
>search engine is available via the SAX or DOM interface offered by many
>parsers.

I disagree.  Few parsers track byte offsets or other locational info in
the file, and I think you need that to do basic things like proximity
and phrase search.

>Of course you don't need to build your own search engine either, all you
>need to do is write an XML filter for an existing search engine. I'm
>surprised no-one seems to have done this yet.

I think you do need to build your own engine.  Reason is, most existing
search engines have an atomic-document view of the world, and break
down completely when asked to model a general recursive hierarchical
structure like 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dip.co.uk  Wed Nov  4 16:39:59 1998
From: rja at dip.co.uk (RJA)
Date: Mon Jun  7 17:06:14 2004
Subject: xml parser
Message-ID: <000101be0811$dbde7c90$c5010180@p197>

>1. Why can't I get it to work?
Lets try to find out.

>Is there anyway to
>get an error from the parser to see what the problem is... maybe a
>getLastError method?  If I get a chance, I may also try it out with
>PerlScript (or VBScript) in ASP later this week.
The error interface has not been exposed in the control  yet.  I'll be doing
that as soon as I get some spare time ( asap ).

I'll download the python compiler and try your sample.

The SAX events are currently being fired using standard COM connection
points, but the event interface is IUnknown based, not IDispatch.  Maybe
thats a problem with Python ?  I'll let you know.

Regards,

Richard.

mailto://RJA@DIP.CO.UK
http://www.arpsolutions.demon.co.uk

*** The text contained within this message is of a personal nature that does
not reflect the development of opinions of data interchange plc unless
specifically stated ***


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Wed Nov  4 16:49:41 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:14 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de> <364077B9.AB1AA3A6@locke.ccil.org>
Message-ID: <36407FC0.D8919AA7@technologist.com>

John Cowan wrote:
> 
> Because I thought XML (and Unicode) were in the business of enabling,
> not constraining.  

XML DTDs are in the business of constraining people to the data models and
data that the software is expecting/can deal with. I don't see any big
difference between saying: "This content must be restricted to this set of
characters" and "this content must be a NMTOKEN or base-64 encoded."

Nevertheless, this is clearly a schema problem and CDATA sections seem to
me to be a really bad tool for enforcing this distinction. No editor
vendor is going to support that use for them so it is a moot point.

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

The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Wed Nov  4 17:00:00 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:14 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de> <364077B9.AB1AA3A6@locke.ccil.org> <36407FC0.D8919AA7@technologist.com>
Message-ID: <36408848.12498760@locke.ccil.org>

Paul Prescod wrote:

> XML DTDs are in the business of constraining people to the data models and
> data that the software is expecting/can deal with. I don't see any big
> difference between saying: "This content must be restricted to this set of
> characters" and "this content must be a NMTOKEN or base-64 encoded."

Put that way, I suppose you are right.  As I said before, this could and
should be handled as a special case of "The character data of this
element must conform to the following regular expression."

> Nevertheless, this is clearly a schema problem and CDATA sections seem to
> me to be a really bad tool for enforcing this distinction.

Particularly because it would mean that the charset of an XML document
would become part of its schema: a document in US-ASCII can have
only ASCII in its CDATA sections, but if it were transcoded to
ShiftJIS, then it could have any JIS X 208 character in the
CDATA section.

So this means that transcoding arbitrary XML documents *requires*
parsing them, because if you are reducing the repertoire, you may need
to break up CDATA sections, and you cannot (?) recognize a
CDATA section reliably without parsing.  (In particular, what
looks like a CDATA section start/end could appear as an attribute
value, PI data, or comment.)  An interesting side effect!

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From clovett at microsoft.com  Wed Nov  4 17:40:52 1998
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:06:14 2004
Subject: CDATA by any other name... (was The raw and the cooked)
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C08743F15@RED-MSG-56>

I like Rick's idea of xml:content-mode="CDATA".  This definitely
disambiguates this whitespace case for the validating parser.

So 
  <!DOCTYPE a [
    <!ELEMENT a (b, c)>
    <!ELEMENT b EMPTY>
    <!ELEMENT c EMPTY>
  ]>
  <a><![CDATA[  ]]><b/><c/></a>

would become:

  <!DOCTYPE a [
    <!ELEMENT a (b, c)>
    <!ATTLIST a xml:content-mode CDATA #FIXED "CDATA">
    <!ELEMENT b EMPTY>
    <!ELEMENT c EMPTY>
  ]>
  <a>  <b/><c/></a>

It's true that a non-validating parser will have difficulty with the latter
example, but that is solved by putting the xml:content-mode attribute on the
instance.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From avirr at LanMinds.Com  Wed Nov  4 18:30:48 1998
From: avirr at LanMinds.Com (Avi Rappoport)
Date: Mon Jun  7 17:06:14 2004
Subject: xml parser
In-Reply-To: <3.0.32.19981104081951.00b61b10@pop.intergate.bc.ca>
Message-ID: <v04102704b2664b1123f6@[207.33.50.55]>

At 8:22 AM -0800 11/4/98, Tim Bray wrote:
> At 10:55 AM 11/4/98 -0000, Michael Kay wrote:
> >My immediate answer to this is yes, all the information you need for a
> >search engine is available via the SAX or DOM interface offered by many
> >parsers.
>
> I disagree.  Few parsers track byte offsets or other locational info in
> the file, and I think you need that to do basic things like proximity
> and phrase search.

What Tim said.  Most search engines do not have database storage, they have 
a fairly simple inverted index.  Trying to put all the XML info in there 
would overload them.  The point of having an XML search is to have metadata 
and context, so you probably need to use some of the more sophisticated 
text retrieval and library systems.

BTW, I'm trying to collect information on XML and search, so please keep me 
posted if you are working on something.  I post everything I hear about at 
<http://www.searchtools.com/related/xml.html>

Avi
________________________________________________________________
Avi Rappoport, Web Site Search Tools Maven: <mailto:avirr@lanminds.com>
Guide to Site Indexing and Local 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From bckman at ix.netcom.com  Wed Nov  4 20:18:13 1998
From: bckman at ix.netcom.com (Frank Boumphrey)
Date: Mon Jun  7 17:06:14 2004
Subject: W3 DOM tutorial.
Message-ID: <000701be0830$133a68c0$16afdccf@ix.netcom.com>

(cross posted to xml-dev)

For those who may be interested, now that Microsoft have released the new
version of their IE5 beta, I have posted a new tutorial on the DOM at
www.hypermedic.com.
Follow the DOM links.

Regards
Frank
Frank Boumphrey

XML and style sheet info at Http://www.hypermedic.com/style/index.htm
Author: - Professional Style Sheets for HTML and XML http://www.wrox.com
CoAuthor: Professional XML applications form Wrox Press, www.wrox.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Suli.Ding at geis.ge.com  Wed Nov  4 22:23:17 1998
From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS))
Date: Mon Jun  7 17:06:14 2004
Subject: Text file to XML??
Message-ID: <F2A665AC0054D1119D0F00805FFECA12019152F9@roc01bxgeisge>

Scott,

Have you check out this URL
	http://www.geocities.com/SiliconValley/Platform/4871/

Regards,

Suli

> ----------
> From: 	Roth, Scott[SMTP:sroth@radsys.com]
> Reply To: 	Roth, Scott
> Sent: 	Wednesday, November 04, 1998 10:28 AM
> To: 	XML Dev Mailing (E-mail)
> Subject: 	Text file to XML??
> 
> Help....???
> 
> I am working on a way to take delimited text file that has data in it and
> break that up so that I can make files that hold xml data within it.  The
> text file holds metadata already that points to files and holds certain
> key
> information.  What I want to do is take that data and have it put the
> proper
> xml tags in where the fields are and then take that data and put it also
> into the file.  Then I want to add the proper HTML. Does this make
> sense???
> 
> Please help me out I want to know if anybody out there has done this
> already
> so I don't have to reinvent the wheel.  And if anyone has any helpful
> hints
> please let me know.  
> 
> Thanks,
> 
> Scott Roth
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Wed Nov  4 22:27:45 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:14 2004
Subject: Interface name quandry ...
In-Reply-To: <c=US%a=_%p=Cromwell_Media%l=ODIN-981104151435Z-6155@odin.cromwellmedia.co.uk>
References: <c=US%a=_%p=Cromwell_Media%l=ODIN-981104151435Z-6155@odin.cromwellmedia.co.uk>
Message-ID: <13888.54350.64691.396015@localhost.localdomain>

[cross-postings removed]

Miles Sabin writes:

 > I'm working on a number of Java APIs which operate
 > on documents and their DOM representations relying
 > on only the intersection of the properties of XML
 > and HTML, and I've been racking my brains for a
 > good name that covers both HTML and XML, but isn't
 > as general as SGML.
 > 
 > Has anybody got any suggestions?

I think that the DOM calls these the "fundamental" node types, but I
don't have the REC in front of me right now to check.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  4 22:33:58 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:14 2004
Subject: SAX, DOM, and Search Engines (was Re: xml parser)
In-Reply-To: <3.0.32.19981104081951.00b61b10@pop.intergate.bc.ca>
References: <3.0.32.19981104081951.00b61b10@pop.intergate.bc.ca>
Message-ID: <13888.54487.434062.193573@localhost.localdomain>

Tim Bray writes:

 > At 10:55 AM 11/4/98 -0000, Michael Kay wrote:
 > >My immediate answer to this is yes, all the information you need for a
 > >search engine is available via the SAX or DOM interface offered by many
 > >parsers.
 > 
 > I disagree.  Few parsers track byte offsets or other locational info in
 > the file, and I think you need that to do basic things like proximity
 > and phrase search.

I disagree.  While byte offsets might be useful for other purposes,
they would be inappropriate for proximity and phrase searches -- for
those, you need to track the relative positions of words, not their
absolute positions.  Consider the following example:

  <p>WORD1 &x; WORD2</p>

Is WORD1 close to WORD2?  It's only five bytes away (assuming an 8-bit
encoding), but might be separated by 20,000 words, depending on what
&x; expands to.  SAX and the DOM do give you enough information to
determine the relative positions of words.

Byte offsets would be helpful for displaying context around a match,
but there would be no 100% reliable way to format that context without
starting from the top of the document, in which case an XPOINTER (also
derivable from SAX or DOM) might be more helpful unless you want the
search engine to display raw XML markup for the context.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  4 23:08:59 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:15 2004
Subject: SAX, DOM, and Search Engines (was Re: xml parser)
Message-ID: <3.0.32.19981104150834.00b4f100@pop.intergate.bc.ca>

At 05:32 PM 11/4/98 -0500, david@megginson.com wrote:
>Tim Bray writes:
> > I disagree.  Few parsers track byte offsets or other locational info in
> > the file, and I think you need that to do basic things like proximity
> > and phrase search.
>
>I disagree.  While byte offsets might be useful for other purposes,
>they would be inappropriate for proximity and phrase searches -- for
>those, you need to track the relative positions of words, not their
>absolute positions.  Consider the following example:
>
>  <p>WORD1 &x; WORD2</p>
>Is WORD1 close to WORD2?

Clearly, the proximity tests have to work in terms of proximity in the
cooked, not raw, text.  Lark carefully tracks offsets in terms of the
entity stack so you can do this.  But that's so obvious I don't think 
it's your point. 

Secondly, for proximity, you're worried about counting characters, not 
bytes, but for addressing back into the entity, you're worried about byte, 
not character, offsets.  So it's even harder than it looks.  Unless
of course you're using UTF16 and staying in the BMP - which might be
a REAL good idea in an IR-oriented system anyhow. 

>  It's only five bytes away (assuming an 8-bit
>encoding), but might be separated by 20,000 words, depending on what
>&x; expands to.  SAX and the DOM do give you enough information to
>determine the relative positions of words.

[warning: simple argument with long embedded digression]
I don't think so.  How about languages, such as those spoken by the
majority of the world's inhabitants, that do not separate words with
spaces?  (Identifying word breaks in running Japanese or Chinese
text is essentially a strong-AI problem.  You can get decent results
by running a dictionary and searching at each character break for
a match, with morphological heuristics, but it turns out that in those
languages there is sufficient encoding redundancy that you get pretty
good results (at a cost of some space wasteage) just treating most 
characters as words - and lurking in that fact there's a PhD in 
linguistics for someone - but I digress, I spent a long time
in those particular mines).  

But spotting "words" may not matter.  In fact, I am not aware of 
any research that shows word proximity to be a better information 
retrieval heuristic than character proximity.  And it's much easier
to nail down what you mean by "character" than "word", and thus get
deterministic cross-language behavior.

>Byte offsets would be helpful for displaying context around a match,
>but there would be no 100% reliable way to format that context without
>starting from the top of the document

unless you used the whizzy new soon-to-arrive W3C fragment packager,
right?  Actually, if you have an index that can understand the the
structure well enough to support xpointer-flavor querying, the engine
is going to know all the context info, so this should actually work
pretty well (but only if you know the byte/character offsets).

And the right way to display results in context depends on whether
you're sampling, or visiting match.

OK, you've been warned... if you get me going on the problems of 
searching in tagged internationalized text, bring a windbreaker -
you'll need it.  -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From salur at csee.wvu.edu  Wed Nov  4 23:23:38 1998
From: salur at csee.wvu.edu (Salur Prashanth)
Date: Mon Jun  7 17:06:15 2004
Subject: XML Search Engine
Message-ID: <Pine.GSO.4.05.9811041817330.2014-100000@naur.csee.wvu.edu>


Hi all,
Can anyone tell me where the difference lies in implementing a search
engine for HTML and a search engine for XML.

Thanks
Salur.

@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#
       					        Address:
					        --------
Prashanth Kumar Salur,				Apt# 910-1,
Graduate Student, CSEE,				445 Oakland Street,
West Virginia University			Morgantown,WV-26505
Off. Ph: 304 293 6371 Ext 577 			Res Ph: 304 598 8025
@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ralph at fsc.fujitsu.com  Thu Nov  5 00:02:32 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:15 2004
Subject: HyBrick V0.8 with XLink/XPointer is now Available
Message-ID: <3.0.5.32.19981105065829.00956a80@pophost.fsc.fujitsu.com>

All,

The latest version of Fujitsu's "HyBrick" browser, V0.8, with support for
XLink/XPointer, is now available from Fujitsu's Web site: 

http://www.fujitsu.co.jp/hypertext/free/HyBrick/download2.html

The browser and supporting documentation can be downloaded by clicking on
hb.08.exe.
 
This is a Japanese-language site, so much of the supporting documentation
won't be accessible to non-Japanese readers. A brief summary:

Features:

- HyBrick includes a DSSSL renderer and XLink/XPointer engine running on
top of SP and Jade
- XLink/XPointer are supported on the local file system
- XPointer is implemented as a subset of the HyTime property set
- Link traversal can use either "New" or "Replace" to display a new page

Using HyBrick:

- HyBrick is supplied as a self-extracting file.
- Once the files are installed, start HyBrick from the bin directory. 
- Use the "Browse" button to open the file sample\docs\readme.xml.
- Click on blue-highlighted areas with the left mouse button to see a list
of locations linked to the highlighted location. If only one location is
available, traversal to that location is immediate.
- Click on blue-highlighted areas with the right mouse button to see the
location of that area expressed as an XPointer.

Contact info:

Please address questions and comments to:

hb-staff@ml.flab.fujitsu.co.jp


Best regards,

Ralph E. Ferris
Fujitsu Software Corporation
ralph@fsc.fujitsu.com




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Thu Nov  5 00:16:56 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:15 2004
Subject: C++ XML Parser
Message-ID: <00153772.3096@datacard.com>

     Hi:
     
     Please point me to the API of any C++ XML Parser -
     I am using IE5.0 - I cannot find any example to
     follow - Someone please help.
     
     Thanks,
     
     SeanN


     

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Thu Nov  5 00:24:52 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:15 2004
Subject: WHERE: mshtml.h  msxml.h 
Message-ID: <0015378C.3096@datacard.com>

     Hi:
     
I installed IE5.0 and I looked for the two header file mshtml.h  msxml.h -
I couldn't find them? Do I need anything else to use C++ XML Parser in
IE5.0?

Please englighten me,

SeanN


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From v-jmurr at microsoft.com  Thu Nov  5 04:20:14 1998
From: v-jmurr at microsoft.com (John Murray (Murray Info Serv. inc.))
Date: Mon Jun  7 17:06:15 2004
Subject: C++ samples, XML DOM doc
Message-ID: <B9D1827FDF66D111925800805F3102E30A3736AF@RED-MSG-57>

    C++ examples:
http://www.microsoft.com/gallery/samples/xml/c++_samples/default.asp
    XML DOM reference:
http://www.microsoft.com/workshop/xml/xmldom/reference/start.asp
Thanks
John

     From: Sung_Nguyen@datacard.com (Sung Nguyen)
     Date: Wed, 4 Nov 1998 18:21:37 -0600
     Subject: WHERE: mshtml.h  msxml.h 
     Hi:
     Please point me to the API of any C++ XML Parser -
     I am using IE5.0 - I cannot find any example to
     follow - Someone please help.
     Thanks,
     SeanN


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Thu Nov  5 05:45:17 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:15 2004
Subject: Unicode, xml:lang, and variant glyphs
In-Reply-To: <363F657F.5D2E1B43@locke.ccil.org>
Message-ID: <002101be087f$a6d02440$d9e887cb@NT.JELLIFFE.COM.AU>


> From:   John Cowan

> Rick Jelliffe wrote:

> > The primary purpose of xml:lang, as far as I am concerned, should be to
> > convey the information lost by ISO 10646 unification: where the
> > Japanese and Chinese glyphs
>
> Actually, the problem isn't that clearcut.  As John Jenkins posted
> to the Unicode list last year:
> (..Lots of facts..)

FACT: Many times that someone says two characters are variants and should be
unified, someone else has used them not as variants. Hence the Unicode
compatability area.

> > (or Polish and Russian)
>
> How's that again?

Oops I meant Russian and Bylorussian (or Khazak or Ukrainian) where some of
the national characters have a different form.

> It doesn't lose information about meaning.  It may make characters
> harder to read, but the distinction is one of typographic tradition,
> not language, and can cross languages.

Are you are saying that characters carry information, and never glyphs (or
character + locale + markup)? You cannot say this without knowing the domain
and purpose of the text: if it is mathematics, then the font definitely
carries information that the unified character does not. If you have a
multi-language dictionary or a list of names which requires exactness, the
font (or markup which selects the font) again is important.

"Harder to read" is no criterion at all. If it is harder to read, it is
because it has lost information.


Rick Jelliffe

Independent XML/SGML Consultant: FM+SGML a speciality
Research Assistant:Computing Center, Academia Sinica, Taipei
Author: The XML & SGML Cookbook, Recipes for Structured Information, 1998


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Thu Nov  5 12:31:28 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:15 2004
Subject: XML Search Engine
Message-ID: <002001be08b7$9dbdeda0$7008e391@bra01wmhkay.bra01.icl.co.uk>

>Hi all,
>Can anyone tell me where the difference lies in implementing a search
>engine for HTML and a search engine for XML.


The main difference is that in HTML the tagging is almost useless in
localising the query, whereas in XML it is potentially very valuable. Many
search engines support field-oriented query, e.g. find "Ireland" as a
surname; with the right input filter for XML it becomes possible to map XML
elements to the fields understood by the search engine, making such queries
a feasible proposition, which is not the case for HTML.

Switching thrreads, I am a little surprised by Tim's remarks on word
proximity versus character proximity. Confining our attention to European
languages (as most search engines do), word proximity searching is a common
feature of the high-end search engines, whereas character proximity is
hardly found outside basic desktop tools like grep. Apart from anything
else, once you've done the word normalisation (normalising different
linguistic forms or spellings of the same word), character proximity is
meaningless. In the older boolean engines word proximity is used rather
mechanistically, in the newer engines it is used more subtly as part of a
statistical or linguistic approach to relevance ranking, but either way it
is an established feature of the scene, and it is not there on whim: the
search algorithms used are based on extensive research and benchmarking of
relevance and recall scores.

An interesting comparison of web search engines is at
http://www.netstrider.com/search/features.html ; this asserts that all the
well-known web search engines other than Lycos use word proximity matching.
(A good survey in spite of the fact that it fails to distinguish the
effectiveness of the query matcher from the effectiveness of the web
crawler)

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From kurt at simberg.com  Thu Nov  5 13:03:18 1998
From: kurt at simberg.com (Kurt Helenelund)
Date: Mon Jun  7 17:06:15 2004
Subject: Creation of XML documents
Message-ID: <3641A21B.E5E4513D@simberg.com>

I am working on a project where we will use XML to exchange information
between
applications in different government agenices. We want to implement both
on-line access
between applications and asynchronous store & forward type of
mechanisms.

I understand that there are 'lots' of good XML parsers (we have tried
some) out there and that SAX and DOM are
the prefered ways for applications to 'read' XML structures. I would
like to ask if there's anyone
that have the opposite problem i.e. for applications to create XML
documents on-the-fly. Of course
the developer could 'hand code' the XML structures which is error prone
and booring . I am looking
for something (API, lib) so that we could avoid this.

I would like to have a 'library' to which the application developer
could say 'using this DTD please
instantiate a XML document and help me to fill it in'.

Any solutions?


--
_______________________________________________________________________
Kurt Helenelund                                Mobile: +358 50 555 0192
Simberg & Partners                             Home:   +358 9  294 0313
Mielikintie 7B                                 Fax:    +358 9  294 0314
FIN-04230 KERAVA, Finland                      Email:  kurt@simberg.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From richard at cogsci.ed.ac.uk  Thu Nov  5 13:40:02 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:15 2004
Subject: Character and byte offsets
In-Reply-To: Tim Bray's message of Wed, 04 Nov 1998 15:08:39 -0800
Message-ID: <199811051339.NAA00077@cogsci.ed.ac.uk>

> Secondly, for proximity, you're worried about counting characters, not 
> bytes, but for addressing back into the entity, you're worried about byte, 
> not character, offsets.  So it's even harder than it looks.

This reminds me - are there good techniques for maintaining a byte
offset in conjunction with character-set translations?  Ideally you
want the translation done in big blocks at a low level, but then how
do you access the byte offsets?  In RXP/LTXML I keep the offset of the
start of the block (which is actually a line), and then (in the case
of UTF-8) effectively reverse-translate to calculate how much to add
(this relies on UTF-8 being invertible).  Surely there must be a better
way...

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


From north at Synopsys.COM  Thu Nov  5 13:52:50 1998
From: north at Synopsys.COM (Simon North)
Date: Mon Jun  7 17:06:15 2004
Subject: XML and IE5 beta PR2
Message-ID: <199811051350.OAA03527@goofy.gr05.synopsys.com>

For anyone who hasn't noticed, the preview 2 release of IE5 was put 
on the public servers yesterday (it had been placed there last Friday 
but was pulled shortly afterwards). Today, Microsoft appear to have 
put updated documentation on the SBN web pages. 

The new release doesn't seem to support the style part of XSL, only 
the transformation part (but it does seem to be nearly 100% 
compliant, or at least as far as I've had time to check). It will, 
for example, choke on process-children (unless someone else has 
got it to work). 

I have managed to get it to work with simple files such as 
these: 

The XML file:

<?xml version="1.0"?>
<?xml:stylesheet type="text/xsl" href="ietest.xsl"?>

<books>
  <book>
    <title>Pierre: The Ambiguities</title>
    <author>Herman Melville</author>
    <price>9.99</price>
  </book>
  <book>
    <title>Heart of Darkness</title>
    <author>Joseph Conrad</author>
    <price>12.99</price>
  </book>
  <book>
    <title>Arrowsmith</title>
    <author>Sinclair Lewis</author>
    <price>8.99</price>
  </book>
  <book>
    <title>Oedipus Rex</title>
    <author>Sophocles</author>
    <price>8.99</price>
  </book>
  <book>
    <title>The Secret Sharer and Other Stories</title>
    <author>Joseph Conrad</author>
    <price>13.99</price>
  </book>
  <book>
    <title>The Republic</title>
    <author>Plato</author>
    <price>12.99</price>
  </book>
  <book>
    <title>The Republic</title>
    <author>Plato</author>
    <price>15.99</price>
  </book>
  <book>
    <title>Pragmatism</title>
    <author>William James</author>
    <price>15.99</price>
  </book>
</books>


and the XSL file:

<DIV xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<TABLE style="table-layout:fixed" BORDER="2" CELLSPACING="2">
  <col width="300"/>
  <col width="300"/>
  <col width="100"/>
  <THEAD>
    <TH>TITLE</TH><TH>AUTHOR</TH><TH>PRICE</TH></THEAD>
  <xsl:for-each select="books/book">
  <TR>
    <TD><SPAN><xsl:value-of select="title"/></SPAN></TD>
    <TD><SPAN><xsl:value-of select="author"/></SPAN></TD>
    <TD><SPAN><xsl:value-of select="price"/></SPAN></TD>
  </TR>
  </xsl:for-each>
</TABLE>
</DIV>

(I quickly hacked these files from the sources available on the SBN 
site). 

Without a style sheet, it shows a 'raw' XML tree that you can expand 
and contract. The DSO and data island mechanisms appear to be intact 
(bar a few minor changes). 

It also appears to correctly parse and validate XML code against a 
DTD; the DTD display is suppressed. 

I'm now going to tackle XLink and XPointer, although I suspect I know 
what the results will be. 

Simon.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ramesh.kasetty at trane.com  Thu Nov  5 14:30:31 1998
From: ramesh.kasetty at trane.com (Kasetty, Ramesh)
Date: Mon Jun  7 17:06:15 2004
Subject: html, xml
Message-ID: <199811051429.IAA05529@nacg.trane.com>

Hi,

I have knowledge of HTML and trying to learn XML. Can anyone tell me the
difference between HTML and XML and where XML can used.

Thanks in advance,
Ramesh
ramesh.kasetty@trane.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jborden at mediaone.net  Thu Nov  5 14:58:46 1998
From: jborden at mediaone.net (Borden, Jonathan)
Date: Mon Jun  7 17:06:15 2004
Subject: FW: Creation of XML documents
Message-ID: <003d01be08cc$9e9e07e0$d3228018@jabr.ne.mediaone.net>

There are several answers to this problem, including XML generation classes.
A standard way to do this is to persist your data into a DOM object and then
ask it to save itself. You might look at Jade (http://www.jclark.com) or
IBM's xml4j as a start.

Jonathan Borden
JABR Technolgy

>
>
> I am working on a project where we will use XML to exchange information
> between
> applications in different government agenices. We want to implement both
> on-line access
> between applications and asynchronous store & forward type of
> mechanisms.
>
> I understand that there are 'lots' of good XML parsers (we have tried
> some) out there and that SAX and DOM are
> the prefered ways for applications to 'read' XML structures. I would
> like to ask if there's anyone
> that have the opposite problem i.e. for applications to create XML
> documents on-the-fly. Of course
> the developer could 'hand code' the XML structures which is error prone
> and booring . I am looking
> for something (API, lib) so that we could avoid this.
>
> I would like to have a 'library' to which the application developer
> could say 'using this DTD please
> instantiate a XML document and help me to fill it in'.
>
> Any solutions?
>
>

>
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jhb at software-ag.de  Thu Nov  5 15:10:32 1998
From: jhb at software-ag.de (Juliane Harbarth)
Date: Mon Jun  7 17:06:15 2004
Subject: html, xml
Message-ID: <008201be08d6$b368dc90$4ba2bd9d@pcjhb.software-ag.de>


-----Original Message-----
From: Kasetty, Ramesh <ramesh.kasetty@trane.com>
To: 'xml-dev@ic.ac.uk' <xml-dev@ic.ac.uk>
Date: Thursday, November 05, 1998 2:43 PM
Subject: html, xml


Kasetty, Ramesh >I have knowledge of HTML and trying to learn XML. Can
anyone tell me the
Kasetty, Ramesh >difference between HTML and XML and where XML can used.


HTML uses a fixed set of tags, to specify display properties for those
things
enclosed in the tags. XML allows the definition of tags that enable the
specification of semantic properties.
In my opinion XML offers the great benefit of being more processable by
machines than HTML. That especially holds for retrieval. Who wants to know
whether a certain document contains '1234' within <P>-Tags ? But a
question like 'which document contains 1234 as an Employee-Number'
makes sense.

Juliane Harbarth
Technical Consultant
Software AG Germany
mailto:jhb@software-ag.de

Tel +49 (0)6151 92 1147


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Thu Nov  5 15:55:28 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:15 2004
Subject: Unicode, xml:lang, and variant glyphs
Message-ID: <3.0.32.19981105075248.00b18610@pop.intergate.bc.ca>

At 04:46 PM 11/5/98 +1100, Rick Jelliffe wrote:
>> > The primary purpose of xml:lang, as far as I am concerned, should be to
>> > convey the information lost by ISO 10646 unification: where the
>> > Japanese and Chinese glyphs

The *only* purpose of xml:lang is to say what language it's in.
You need to know this for a *lot* more than picking glyphs. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov  5 17:16:29 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:15 2004
Subject: Unicode, xml:lang, and variant glyphs
References: <002101be087f$a6d02440$d9e887cb@NT.JELLIFFE.COM.AU>
Message-ID: <3641DD79.2DD20660@locke.ccil.org>

Rick Jelliffe wrote:

> FACT: Many times that someone says two characters are variants and should be
> unified, someone else has used them not as variants. Hence the Unicode
> compatability area.

Unicode had to be round-trip compatible with many character sets formed
on different principles.  The KSC character sets, e.g. encode some
hanja (Chinese character) more than once if they have more than
one meaning, for the sake of making hanja-hangeul conversions easy.
Nobody denies that these are the same *characters*; even their glyphs
are bit for bit the same.

> Oops I meant Russian and Bylorussian (or Khazak or Ukrainian) where some of
> the national characters have a different form.

I don't know about this.  Are there really glyphic differences?
I know about the character-level differences, like Ukrainian using
GHE WITH STROKE except for a period from Stalin till a few years
ago, when they were forced to use GHE indiscriminately for GHE and
GHE WITH STROKE.

I also know about Polish accents, which are properly placed lower
over the character than similar-looking Western accents.  That
certainly is a glyph difference that fine Polish typography should
take into account, but getting it wrong does not interfere with
*meaning*: it is not a plaintext distinction.  (See below.)

A borderline case is 8859-2's use of S WITH CEDILLA and T WITH
CEDILLA to represent Romanian's S and T WITH COMMA BELOW.  This is
finally being undone, so that Turkish can keep S WITH CEDILLA and
Romanian will get a proper S WITH COMMA BELOW.  (Nobody actually
needs T WITH CEDILLA.)  My *National Geographic* world map uses
S WITH CEDILLA in Romanian place names, but you have to look closely
and compare with Turkish place names to be sure.
 
> Are you are saying that characters carry information, and never glyphs (or
> character + locale + markup)?

No, I am talking about the CJK case specifically.  A unified font
may look ugly, and certainly shouldn't be used for fine typography,
but a language indicator is neither necessary nor sufficient to
solve this problem.

This is not to say that in documents to be finely rendered, an
attribute called "cjkv-typographic-tradition" might not be
useful.

> if it is mathematics, then the font definitely
> carries information that the unified character does not.

Which is why there are a whole bunch of "letterlike symbols" for
math purposes.

> If you have a
> multi-language dictionary or a list of names which requires exactness, the
> font (or markup which selects the font) again is important.

Sure, font is important when it's important.  My claim is confined
to this: that for plain-text purposes, Han unification does not
obscure anything essential.
 
> "Harder to read" is no criterion at all. If it is harder to read, it is
> because it has lost information.

Au contraire.  The Unicode definition of a "plain text distinction"
is one which is necessary for mere legibility.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Thu Nov  5 17:40:39 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:16 2004
Subject: FW: Creation of XML documents
References: <003d01be08cc$9e9e07e0$d3228018@jabr.ne.mediaone.net>
Message-ID: <3641E353.4256F5FF@locke.ccil.org>

Borden, Jonathan wrote:

> A standard way to do this is to persist your data into a DOM object and then
> ask it to save itself. You might look at Jade (http://www.jclark.com) or
> IBM's xml4j as a start.

Alas, the DOM does not provide a standardized way for objects to
"save themselves".

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Thu Nov  5 17:52:41 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:16 2004
Subject: XML Search Engine
Message-ID: <3.0.32.19981105094725.009209b0@pop.intergate.bc.ca>

At 12:27 PM 11/5/98 -0000, Michael Kay wrote:
>Switching thrreads, I am a little surprised by Tim's remarks on word
>proximity versus character proximity. Confining our attention to European
>languages (as most search engines do), word proximity searching is a common
>feature of the high-end search engines, whereas character proximity is
>hardly found outside basic desktop tools like grep. 

What I said was:
1. I have not seen any research which demonstrates that word proximity
   achieves better results than character proximity based on any
   well-known IR metric.
2. Doing word proximity at all is a *very* hard problem in the languages
   used by a large majority of the world's population.

>Apart from anything
>else, once you've done the word normalisation (normalising different
>linguistic forms or spellings of the same word), character proximity is
>meaningless. In the older boolean engines word proximity is used rather
>mechanistically, in the newer engines it is used more subtly as part of a
>statistical or linguistic approach to relevance ranking

If you go poking around either in the SIGIR world (that would be the 
Association for Computing Machinery's Special Interest Group on 
Information Retrieval) or in the actual commercial retrieval engine
world, you find a distressing lack of technology progress.  Yes, with
modern engines, precision & recall are measurably better than they
were in 1978.  But 10 times as good?  Hah!  Twice as good?  Maybe,
for certain restricted application domains.  Given all this, I'm
less than impressed about the subtle techniques of modern engines.
On top of which, most of the techniques used in the "advanced" engines
are basically Anglocentric and fall apart once you get outside the
English-speaking world.

> but either way it
>is an established feature of the scene, and it is not there on whim: the
>search algorithms used are based on extensive research and benchmarking of
>relevance and recall scores.

Yeah, well, it's *not* an established feature of the scene in Asia.  Maybe
it's just an irrational prejudice, but I'm not all that interested in
computing techniques that are not usable by a large majority of the
world's population.  And once again, I challenge the assertion that,
for all these clever heuristics, real-world retrieval software is
really much better than it was 20 years ago.

>An interesting comparison of web search engines is at
>http://www.netstrider.com/search/features.html ; this asserts that all the
>well-known web search engines other than Lycos use word proximity matching.

And we know what wonderful results they produce (that's in English; for
real joy, go try a tricky in German - even European languages sometimes
leave out the spaces between the words - and see what happens).  -Tim

PS: Given my grouchy tone, I should say that I'm dazzled at the
inventiveness, deep thought, and creativity that have been invested
in the IR field in recent decades.  The fact the results are so
underwhelming is evidence of how hard the problems are... the real
lesson is that we should marvel at the language-processing apparatus
we carry around between our ears. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From avirr at LanMinds.Com  Thu Nov  5 18:04:03 1998
From: avirr at LanMinds.Com (Avi Rappoport)
Date: Mon Jun  7 17:06:16 2004
Subject: html, xml
In-Reply-To: <008201be08d6$b368dc90$4ba2bd9d@pcjhb.software-ag.de>
Message-ID: <v04102706b267985394c1@[207.33.50.55]>


> Kasetty, Ramesh >I have knowledge of HTML and trying to learn XML. Can
> anyone tell me the
> Kasetty, Ramesh >difference between HTML and XML and where XML can used.
>
>
> HTML uses a fixed set of tags, to specify display properties for those
> things
> enclosed in the tags. XML allows the definition of tags that enable the
> specification of semantic properties.
> In my opinion XML offers the great benefit of being more processable by
> machines than HTML. That especially holds for retrieval. Who wants to know
> whether a certain document contains '1234' within <P>-Tags ? But a
> question like 'which document contains 1234 as an Employee-Number'
> makes sense.

While I'm obsessed with search and XML, I think that's not going to be the 
short-term gain with XML.

XML is not a set of tags like HTML, it's a set of simple rules for defining 
tags for your own content.  This lets you use XML files for data 
interchange.  Eventually, you'll be able to post them to the Web with 
associated style sheets and people will view them (but not until 5.0 
browsers come out).

There are major advantages for using XML files for data storage and 
especialy for data interchange.  XML formats are basically self-documenting 
and are meant to be both human and machine-readable.  That means that you 
will be able to read the file in 10 or 20 years, unlike most other data 
structures.  You can read and write a valid XML file from any 
XML-generating application, so you aren't locked into a single program with 
a proprietary file format.  It's based on Unicode, so it's not limited to 
Western languages.  While XML is not very efficient for database access, 
database programs can read and write XML files very easily.

For more information, see <http://www.xml.com/>, the FAQs at 
<http://netlingo.com/more/xmlfaq.htm>, <http://www.ucc.ie/xml/> and the 
news page at <http://www.oasis-open.org/cover/sgmlnew.html>.

Hope that helps!

Avi
________________________________________________________________
Avi Rappoport, Web Site Search Tools Maven: <mailto:avirr@lanminds.com>
Guide to Site Indexing and Local 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jborden at mediaone.net  Thu Nov  5 18:21:03 1998
From: jborden at mediaone.net (Borden, Jonathan)
Date: Mon Jun  7 17:06:16 2004
Subject: XML Search Engine
In-Reply-To: <3.0.32.19981105094725.009209b0@pop.intergate.bc.ca>
Message-ID: <005901be08e8$e1c63210$d3228018@jabr.ne.mediaone.net>

As you say Word/Character proximity searching is not that interesting, and
if this is desired, XML doesn't have much to add to the current equation.

On the other hand grove based proximity search techniques have also been
used since the 1970's when this was called a "semantic network". the
advantage is that it is language independent. To date, this hasn't been
terribly useful with HTML as not many people care about indexing <p> tags
for example. This where XML has lots to offer and where efforts ought to and
are being directed (IHMO).

Jonathan Borden
JABR Technology
http://jabr.ne.mediaone.net

Tim Bray wrote:
>
>
> At 12:27 PM 11/5/98 -0000, Michael Kay wrote:
> >Switching thrreads, I am a little surprised by Tim's remarks on word
> >proximity versus character proximity. Confining our attention to European
> >languages (as most search engines do), word proximity searching
> is a common
> >feature of the high-end search engines, whereas character proximity is
> >hardly found outside basic desktop tools like grep.
>
> What I said was:
> 1. I have not seen any research which demonstrates that word proximity
>    achieves better results than character proximity based on any
>    well-known IR metric.
> 2. Doing word proximity at all is a *very* hard problem in the languages
>    used by a large majority of the world's population.
>
> >Apart from anything
> >else, once you've done the word normalisation (normalising different
> >linguistic forms or spellings of the same word), character proximity is
> >meaningless. In the older boolean engines word proximity is used rather
> >mechanistically, in the newer engines it is used more subtly as part of a
> >statistical or linguistic approach to relevance ranking
>
> If you go poking around either in the SIGIR world (that would be the
> Association for Computing Machinery's Special Interest Group on
> Information Retrieval) or in the actual commercial retrieval engine
> world, you find a distressing lack of technology progress.  Yes, with
> modern engines, precision & recall are measurably better than they
> were in 1978.  But 10 times as good?  Hah!  Twice as good?  Maybe,
> for certain restricted application domains.  Given all this, I'm
> less than impressed about the subtle techniques of modern engines.
> On top of which, most of the techniques used in the "advanced" engines
> are basically Anglocentric and fall apart once you get outside the
> English-speaking world.
>
> > but either way it
> >is an established feature of the scene, and it is not there on whim: the
> >search algorithms used are based on extensive research and
> benchmarking of
> >relevance and recall scores.
>
> Yeah, well, it's *not* an established feature of the scene in Asia.  Maybe
> it's just an irrational prejudice, but I'm not all that interested in
> computing techniques that are not usable by a large majority of the
> world's population.  And once again, I challenge the assertion that,
> for all these clever heuristics, real-world retrieval software is
> really much better than it was 20 years ago.
>
> >An interesting comparison of web search engines is at
> >http://www.netstrider.com/search/features.html ; this asserts
> that all the
> >well-known web search engines other than Lycos use word
> proximity matching.
>
> And we know what wonderful results they produce (that's in English; for
> real joy, go try a tricky in German - even European languages sometimes
> leave out the spaces between the words - and see what happens).  -Tim
>
> PS: Given my grouchy tone, I should say that I'm dazzled at the
> inventiveness, deep thought, and creativity that have been invested
> in the IR field in recent decades.  The fact the results are so
> underwhelming is evidence of how hard the problems are... the real
> lesson is that we should marvel at the language-processing apparatus
> we carry around between our ears. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  5 18:42:53 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:16 2004
Subject: Creation of XML documents
In-Reply-To: <3641A21B.E5E4513D@simberg.com>
References: <3641A21B.E5E4513D@simberg.com>
Message-ID: <13889.61694.173227.630556@localhost.localdomain>

Kurt Helenelund writes:

 > I would like to ask if there's anyone that have the opposite
 > problem i.e. for applications to create XML documents
 > on-the-fly. Of course the developer could 'hand code' the XML
 > structures which is error prone and booring . I am looking for
 > something (API, lib) so that we could avoid this.

As far as this goes, try using SAX backwards.  There are SAX
applications that produce normalised XML (James Clark's example at
http://www.jclark.com/xml/ might be helpful), and you can just feed
canned SAX events 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jborden at mediaone.net  Thu Nov  5 18:49:58 1998
From: jborden at mediaone.net (Borden, Jonathan)
Date: Mon Jun  7 17:06:16 2004
Subject: Creation of XML documents
In-Reply-To: <3641E353.4256F5FF@locke.ccil.org>
Message-ID: <005a01be08ec$c15cc8a0$d3228018@jabr.ne.mediaone.net>

John Cowan wrote:
>
> Alas, the DOM does not provide a standardized way for objects to
> "save themselves".
>
>

	This is an unfortunate oversight. DOM implementors thus each create a
non-standard mechanism to build a grove.

Jonathan Borden
JABR


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From fernando at pix.com.br  Thu Nov  5 18:52:39 1998
From: fernando at pix.com.br (Fernando Cabral)
Date: Mon Jun  7 17:06:16 2004
Subject: XML Search Engine
References: <005901be08e8$e1c63210$d3228018@jabr.ne.mediaone.net>
Message-ID: <3641ACC1.42FE15C8@pix.com.br>

Borden, Jonathan wrote:

> As you say Word/Character proximity searching is not that interesting, and
> if this is desired, XML doesn't have much to add to the current equation

I beg to disagree twice. a) proximity search is very important for any
one searchingany reasonably-sized database with a variety of texts; b) XML can
help a lot,
even thou most non-XML capable search engines can already offer proximity
searching.

We have bee able to solve quite a number of problems using proximity. If we
did not have it we could still be able to solve those problems albeit spending
much more effort, time, intelligence and CPU cicles.

- fernando

--
Fernando Cabral                         Padrao iX Sistemas Abertos
mailto:fernando@pix.com.br              http://www.pix.com.br
                                        mailto:Pix@Pix.com.br
Fone: +55 61 321-2433                   Fax: +55 61 225-3082
15? 45' 04.9" S                         47? 49' 58.6" W
19? 37' 57.0" S                         45? 17' 13.6" W



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Thu Nov  5 18:55:07 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:16 2004
Subject: XML Search Engine
In-Reply-To: <3.0.32.19981105094725.009209b0@pop.intergate.bc.ca>
References: <3.0.32.19981105094725.009209b0@pop.intergate.bc.ca>
Message-ID: <13889.62092.676344.644070@localhost.localdomain>

Tim Bray writes:

 > What I said was:
 > 1. I have not seen any research which demonstrates that word proximity
 >    achieves better results than character proximity based on any
 >    well-known IR metric.
 > 2. Doing word proximity at all is a *very* hard problem in the languages
 >    used by a large majority of the world's population.

I think that there might be a disconnect here.  What we're talking
about is minimal-semantic-unit proximity -- for some
languages/contexts, the minimal semantic unit will always be a single
grapheme, and for others, it will be a cluster of one or more
graphemes.

This type of clustering is critical for search engines, which often
(usually?) provide inverse indexes only for minimal semantic units,
not for all graphemes.  The argument, then, is that proximity testing
should be done by counting the units that were indexed, which may or
may not be single graphemes.


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


From bobp at lightlink.com  Thu Nov  5 19:21:43 1998
From: bobp at lightlink.com (Bob Parks)
Date: Mon Jun  7 17:06:16 2004
Subject: html, xml
In-Reply-To: <v04102706b267985394c1@[207.33.50.55]>
References: <008201be08d6$b368dc90$4ba2bd9d@pcjhb.software-ag.de>
Message-ID: <l03102800b267b6e58ba3@[10.140.1.146]>

Avi,
I have a large reference work - The Wordsmyth English Dictionary-Thesaurus
(WEDT) - on the web at http://www.wordsmyth.net in conjunction with the
University of Chicago's ARTFL Project. I am wondering if the selection and
definition of XML tags  can have a significant impact on the search
possibilities. It is clear that  XML   gives us a chance to mark   semantic
information.  (And a dictionary will give us a chance to create powerful
text parsers  that can mark much more information than part of speech)  But
it isn't   so clear to me how to define tags that will maximize the
flexibility of search routines. Any thoughts?
Regards,
Bob Parks
Associate Professor
Elmira College



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jborden at mediaone.net  Thu Nov  5 19:25:36 1998
From: jborden at mediaone.net (Borden, Jonathan)
Date: Mon Jun  7 17:06:16 2004
Subject: XML Search Engine
Message-ID: <005c01be08f1$c8379920$d3228018@jabr.ne.mediaone.net>

Let me rephrase that: word/character proximity searching has been done for
decades and its utility is well known. The last time I addressed this in
detail was when I spent some time on the Hearsay project which was an early
speech recognition system during the early 1980's. The problem of german or
oriental words/phonemes/sentences etc. is fairly similar (perhaps identical)
to the problem of english language speakers who slur their words together.
Speech processing programs have made great recent strides yet this has been
a difficult nut to crack.

There are many people who believe that further refinements of these well
known techniques are unlikely to yield dramatic improvements. Instead there
are avenues of attack which operate at higher levels on the information food
chain, namely at the word phrase, syntactic and semantic levels. These
levels are well represented as grove structures and XML/SGML search
techniques will likely yield significant results. Natural language
processing algorithms naturally express their output in groves and
intelligent search is at this crossroad.

For example, suppose I am searching for big apples:

"This is a little green apple. Big deal."

will "Big near apple" match?
how about "Big applied to apple"

Jonathan Borden
JABR
http://jabr.ne.mediaone.net

>
>
> Borden, Jonathan wrote:
>
> > As you say Word/Character proximity searching is not that
> interesting, and
> > if this is desired, XML doesn't have much to add to the current equation
>
> I beg to disagree twice. a) proximity search is very important for any
> one searchingany reasonably-sized database with a variety of
> texts; b) XML can
> help a lot,
> even thou most non-XML capable search engines can already offer proximity
> searching.
>
> We have bee able to solve quite a number of problems using
> proximity. If we
> did not have it we could still be able to solve those problems
> albeit spending
> much more effort, time, intelligence and CPU cicles.
>
> - fernando


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tyler at infinet.com  Thu Nov  5 19:27:03 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:16 2004
Subject: Creation of XML documents
References: <3641A21B.E5E4513D@simberg.com>
Message-ID: <3641FBC2.E8D91C6F@infinet.com>

Kurt Helenelund wrote:

> I am working on a project where we will use XML to exchange information
> between
> applications in different government agenices. We want to implement both
> on-line access
> between applications and asynchronous store & forward type of
> mechanisms.
>
> I understand that there are 'lots' of good XML parsers (we have tried
> some) out there and that SAX and DOM are
> the prefered ways for applications to 'read' XML structures. I would
> like to ask if there's anyone
> that have the opposite problem i.e. for applications to create XML
> documents on-the-fly. Of course
> the developer could 'hand code' the XML structures which is error prone
> and booring . I am looking
> for something (API, lib) so that we could avoid this.
>
> I would like to have a 'library' to which the application developer
> could say 'using this DTD please
> instantiate a XML document and help me to fill it in'.
>
> Any solutions?

Build a DOM tree programmatically and write out the contents.  Most DOM packages
support this feature or some form of DOM Writer.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov  5 19:31:24 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:16 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML Application
Message-ID: <3641FCE4.61D46D15@locke.ccil.org>

(Draft 0.1)

This is a report gleaned from the XML recommendation, showing what
an XML processor (validating or non-validating) must report to the
application that invokes it in order to claim conformance to the
XML recommendation.  Numbers in parentheses refer to clauses.

1.  An XML processor must always provide all characters in a
document that are not part of markup to the application.  (2.10)

2.  A validating XML processor must inform the application which
non-markup characters are whitespace appearing within element
content.  (2.10)

3.  An XML processor must pass the single character &#A; in place
of &#D; or &#D;&#A; appearing in its input.

4.  An XML processor must normalize the value of attributes according
to the rules in clause 3.3 before passing them to the application.
This implies that the value of attributes after normalization
are passed to the application.  (3.3)

5.  An XML processor must pass the identifiers of declared unparsed
entities and their associated identifiers to the application.  (4, 4.7)

6.  When the name of an unparsed entity appears as the explicit
or default value of an ENTITY or ENTITIES attribute, an XML
processor must provide the names, system identifiers, and (if present)
public identifiers of both the entity and its notation to the
application (4.6, 4.7)

7.  An XML processor must report well-formedness errors in the
document entity and in any other entities that it reads.  (5.1)

8.  A validating XML processor must report violations of the
constraints expressed in the DTD, and failures to fulfill validity
constraints.  All entities included directly or indirectly by
the document entity must be examined.  (5.1) [The recommendation
is self-contradictory on whether this behavior is required always
or only at user option: see 5.1 vs. the definition of "validity
constraint".]

9.  An XML processor must pass processing instructions to the
application.  (2.6)

10. An XML processor (necessarily a non-validating one) that does
not include the replacement text of an external parsed entity
in place of an entity reference must notify the application that
it recognized but did not read the entity (4.4.3)  [SAX does not
provide for this]

11. A validating XML processor must include the replacement text
of an entity in place of an entity reference.  (5.2)

12.  A validating XML processor must supply the default value
of attributes declared in the DTD for a given element type but
not appearing in the element's start tag.  (5.2)

Have I overlooked anything?

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Thu Nov  5 19:43:22 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:16 2004
Subject: Unicode, xml:lang, and variant glyphs
In-Reply-To: <3641DD79.2DD20660@locke.ccil.org>
Message-ID: <002501be08f4$bbedf850$51ea87cb@NT.JELLIFFE.COM.AU>

Rick:

> > Are you are saying that characters carry information, and never
> > glyphs (or character + locale + markup)?

> From:  John Cowan

> No, I am talking about the CJK case specifically.  A unified font
> may look ugly, and certainly shouldn't be used for fine typography,
> but a language indicator is neither necessary nor sufficient to
> solve this problem.

But I am not thinking "What is sufficient?", I am thinking "Is something
being lost here?" and "how nice is the thing being lost?"

If a XML document arrives with an encoding in the XML header of SJIS it will
have been created on a Japanese editor: in the absense of any information to
the contrary, shouldn't it be displayed using Japanese fonts? And if a
document arrives in Big Five, shouldnt it be displayed in the absense of
anything else, using a (presumably traditional but this is not clear cut
now) Chinese font?

In XML terms, if there is no xml:lang in effect, and the sender wrote using
a different script variant to the receiver, mightn't heuristic defaulting of
xml:lang based on originating character set (and, for example, originating
country in the URL) be the desired behaviour for some?  And if it is desired
in that circumstance, wouldn't it be useful to preserve that information
when cutting-and-pasting documents or transcluding portions. (The XML
encoding PI presumably will not survive in the grove of every document, so I
am not sure it could reliably be available in the case of transcluded data.)

I am very loathe to say "everything that you need to know arrives marked-up
explicitly" in this particular case. For example, if a Japanese document
arrives in XML, and it was originally encoded in shift-JIS, then we should
have a suspicion that when there is a backslash character, a Yen glyph might
be intended. I know that it would be better to encode the document properly
first, but it seems that a policy of choosing a variant font based on the
sending encoding (or for that matter, the country in the URL) is just as
legitimate a default policy as just using the current-locale's variant font
at the receiver.

> My claim is confined
> to this: that for plain-text purposes, Han unification does not
> obscure anything essential.

As far as the plain-text distinction, were laypeople actually tested for
this, or is it the conjecture of scholars who already know all the variants
and their connections (no disrespect intended)? As is the case with fraktur
for English readers, if you have not been taught the characters you cannot
read them, and if you have been taught them you cannot be tested for whether
you can read them.

The plain-text criterion may be good for character-set people. But there is
no reason to assume that preserving minimal readability is a criterion good
enough for documents. I guess this is the PDF versus SGML debate writ small;
should fidelity to the originating publication be the policy or should
rendering be termined by the setup of the receiver. And maybe it is a
content-related thing too: the closer text is to literature or names, the
greater the chance that the sender intends a particular glyph variant for
the character they chose.

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


From M.H.Kay at eng.icl.co.uk  Thu Nov  5 20:08:47 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:16 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML Application
Message-ID: <007501be08f7$7b90e3f0$7008e391@bra01wmhkay.bra01.icl.co.uk>

>Have I overlooked anything?


The interesting thing is that if this list is complete, there are lots of
things the spec doesn't say.

Most notably it doesn't say that the processor must tell the application
anything at all about element tags!

It also doesn't mention anything that the processor mustn't tell the
application, though some of the statements seem to hint that there are
things the application oughtn't to know.

There are some things it doesn't say because they're obvious to everyone,
e.g. that it must retain the order of the characters in the document and not
add any extra ones.

Another thing it doesn't say is when the processor must report an error: in
particular, it would be nice if it insisted that all data passed to the
application before reporting an error must be data that could come from a
valid document. (I've hit this problem recently: to avoid my application
crashing on bad XML, I have to carry out checks that the parser will carry
out anyway, but later)

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Thu Nov  5 20:16:13 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:16 2004
Subject: Creation of XML documents
References: <3641A21B.E5E4513D@simberg.com>
Message-ID: <3642064F.855A5AB5@eng.sun.com>

Kurt Helenelund wrote:
> 
> 	 I would like to ask if there's anyone
> that have the opposite problem i.e. for applications to create XML
> documents on-the-fly.

Like some other packages, Sun's supports this.  (In fact, I've been
a bit surprised how many people call this out as a favorite feature.
Even more than like its speed!)

	http://java.sun.com/jdc/earlyAccess/xml

Our model has thus far been that a complete XML package must support
a basic "round trip" of data -- though excluding the DTD info.  So
it's easy to just use XmlDocument.write (writer) to emit XML text.
Yes, this transparently handles stuff like "&" and "<" in text.

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


From fernando at pix.com.br  Thu Nov  5 20:16:39 1998
From: fernando at pix.com.br (Fernando Cabral)
Date: Mon Jun  7 17:06:17 2004
Subject: XML Search Engine
References: <005c01be08f1$c8379920$d3228018@jabr.ne.mediaone.net>
Message-ID: <3641C09A.746EE929@pix.com.br>

Borden, Jonathan wrote:

> For example, suppose I am searching for big apples:
>
> "This is a little green apple. Big deal."
>
> will "Big near apple" match?
> how about "Big applied to apple"

This will not be a poblem with any "decent" text retrieval engine because:

a) proximity search can be performed either "ordered" or "non-ordered". This is
    quite powerful because it allows you to search for "big near potato" in the
sentece

        "This is a small potato, big brother"

        either to find both "potato, big"  as well as "big, potato" or only one
of the two.
        Some search engine, like Stairs (the grandfather of all text-retrieval
engines)
        and BRS have two operator like "near" (or "prox") and "ADJacent", the
        first one being unordered, the second one being ordered.

b) Usually search engine know what  phrases and paragraphs are. I don't think
     proximity should go beyond a period or any other punctuation that ends
     a sentence. If you want to search in larger units, like a paragraph, then
     you could always define something like "apple SAME PARAGRAPH big"
     or "apple SAME SENTENCE big", both of with extend the idea
     of "nearness" providing a more logical view of the terms.

c) finally, growing from the very close vicinity (near/adjacent) to a little
    further (same sentence/same paragraph) you can go to the whole
    "universe" with AND, OR, XOR, etc. What this means is that
    you can have a very good control not only on which words you
    want, but also where they, how far apart they can be, which one
    comes first...

d) XML allows you to use all the above operators adding a very
    useful feature: tag-qualification.

- fernando

--
Fernando Cabral                         Padrao iX Sistemas Abertos
mailto:fernando@pix.com.br              http://www.pix.com.br
                                        mailto:Pix@Pix.com.br
Fone: +55 61 321-2433                   Fax: +55 61 225-3082
15? 45' 04.9" S                         47? 49' 58.6" W
19? 37' 57.0" S                         45? 17' 13.6" W



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From lauren at sqwest.bc.ca  Thu Nov  5 20:20:40 1998
From: lauren at sqwest.bc.ca (Lauren Wood)
Date: Mon Jun  7 17:06:17 2004
Subject: Creation of XML documents
In-Reply-To: <005a01be08ec$c15cc8a0$d3228018@jabr.ne.mediaone.net>
References: <3641E353.4256F5FF@locke.ccil.org>
Message-ID: <199811052011.MAA05387@sqwest.bc.ca>

At 05/11/1998 10:47 AM , Borden, Jonathan wrote:
>John Cowan wrote:
>>
>> Alas, the DOM does not provide a standardized way for objects to
>> "save themselves".
>
>	This is an unfortunate oversight. DOM implementors thus each create a
>non-standard mechanism to build a grove.

I prefer to call it a "not yet" than an oversight; so far only DOM Level 1
is available. There is lots of work yet to do, including standardised ways
to read documents, serialise documents, validate documents, .... ideas on
prioritising all of this are welcome, but I'd suggest you send them to the
public DOM mailing list (www-dom@w3.org; to subscribe, send email to
www-dom-request@w3.org with the subject "subscribe").

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov  5 21:12:34 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:17 2004
Subject: Unicode, xml:lang, and variant glyphs
References: <002501be08f4$bbedf850$51ea87cb@NT.JELLIFFE.COM.AU>
Message-ID: <364214F7.798593A4@locke.ccil.org>

Rick Jelliffe wrote:

> If a XML document arrives with an encoding in the XML header of SJIS it will
> have been created on a Japanese editor: in the absense of any information to
> the contrary, shouldn't it be displayed using Japanese fonts?

Perhaps as a heuristic.  But I find it very hard to swallow that
the charset encoding of a document is part of its semantics.
Would you assume that, in the absence of other evidence, a
document in ASCII was in en-US?  And if so, what assumption
would you make about a 8859-1 document?

> And if a
> document arrives in Big Five, shouldnt it be displayed in the absense of
> anything else, using a (presumably traditional but this is not clear cut
> now) Chinese font?

Note:  Contrary to a common assumption, Unicode does *not* unify
simplified hanzi with their traditional counterparts.
 
> I am very loathe to say "everything that you need to know arrives marked-up
> explicitly" in this particular case. For example, if a Japanese document
> arrives in XML, and it was originally encoded in shift-JIS, then we should
> have a suspicion that when there is a backslash character, a Yen glyph might
> be intended.

If it is really encoded in SJIS, then an \x5C byte represents
a yen character, not a backslash, and had better be treated as such
by the application.  Of course, since the document character set is
always 10646, a &#x5C; character reference means a backslash, not a
yen symbol.  Ditto for KSC with a won symbol (U+20A9).

> As far as the plain-text distinction, were laypeople actually tested for
> this, or is it the conjecture of scholars who already know all the variants
> and their connections (no disrespect intended)?

I don't know, as I am not part of the Ideographic Rapporteur Group
and find their documents very hard to follow.

> The plain-text criterion may be good for character-set people. But there is
> no reason to assume that preserving minimal readability is a criterion good
> enough for documents.

No doubt it is not.  The point is that anything that is not a plain
text distinction should be encoded using our favorite markup mechanism:
XML.

> I guess this is the PDF versus SGML debate writ small;
> should fidelity to the originating publication be the policy or should
> rendering be termined by the setup of the receiver.

In the end the receiver always controls: a variant PDF renderer
could exist, although there's no reason for it to.  Fidelity to
the originating publication is a reasonable goal, but requires
reasonable cooperation.

> And maybe it is a
> content-related thing too: the closer text is to literature or names, the
> greater the chance that the sender intends a particular glyph variant for
> the character they chose.

Very true, which is why I am interested to hear about methods for
explicitly encoding variants.
 
-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tony.peters at qr.com.au  Thu Nov  5 22:22:27 1998
From: tony.peters at qr.com.au (Tony Peters)
Date: Mon Jun  7 17:06:17 2004
Subject: unsubscribe
Message-ID: <MAPI.Id.0016.00313031313438203030303730303037@MAPI.to.RFC822>

unsubscribe xml-dev


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sharris at primus.com  Thu Nov  5 22:34:37 1998
From: sharris at primus.com (Steve Harris)
Date: Mon Jun  7 17:06:17 2004
Subject: Namespaces - defaulting question (re:WD-xml-names19980916)
Message-ID: <293509DEBE37D211BA5100805F9F92AE5ED3A2@exchange1.primus.com>

Reading the Namespaces specification, I've found contradictory examples
of namespace defaulting. Any input in determining the proper
interpretation would be greatly appreciated.
  The first example is as follows:
<?xml version="1.0"?>
  <x xmlns:edi='http://ecommerce.org/schema'>
  <!-- the edi namespace applies to the "x" element and contents -->
</x>
Here, the inline comment suggests that the element 'x' now lies within
the 'edi' namespace.
  Later in the specification, we find this example (slightly reformatted
for clarity):
<RESERVATION xmlns:HTML="http://www.w3.org/TR/REC-html40">
  <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
  <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT>
  <HTML:A HREF='/cgi-bin/ResStatus'>Check Status</HTML:A>
  <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE>
</RESERVATION>
The specification authors break this instance apart into the 'Expanded
Element Types and Attribute Names' meta-markup to illustrate proper
interpretation. There, the element 'RESERVATION' is not associated with
the namespace prefix 'HTML'. This contradicts the first example's
binding.
  Section 5.2 reads, "A _default namespace_ is considered to apply to
the element where it is declared (if that element has no namespace
prefix), and to all elements with no prefix within the content of that
element." Elsewhere, Section 2 defines the term 'default namespace' as:

	[Definition]: If the colon and NCName are not provided, then the
	associated _namespace name_ is that of a *default namespace*
	in the scope of the element to which the declaration is
attached.

By these two definitions, it sounds like the first example above is
incorrect. The 'edi' prefix should not bind to element 'x' since the
declaration is not a default namespace declaration. Please confirm or
deny this assertion.
  I apologize if this topic has been covered before. Scouring the
archives didn't turn up anything that directly answers the question.


Steven E. Harris
Software Engineer
PRIMUS
1601 Fifth Avenue, Suite 1900
Seattle, Washington 98101

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Thu Nov  5 22:42:36 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:17 2004
Subject: Namespaces - defaulting question (re:WD-xml-names19980916)
References: <293509DEBE37D211BA5100805F9F92AE5ED3A2@exchange1.primus.com>
Message-ID: <36422A22.77C65887@locke.ccil.org>

Steve Harris wrote:

> Reading the Namespaces specification, I've found contradictory examples
> of namespace defaulting. Any input in determining the proper
> interpretation would be greatly appreciated.

Your problem is that you are confusing *scope* with *defaulting*.
The scope of a namespace declaration is the whole of the element
in which it is contained, including the element type.
So the comment below is true:

>   The first example is as follows:
> <?xml version="1.0"?>
>   <x xmlns:edi='http://ecommerce.org/schema'>
>   <!-- the edi namespace applies to the "x" element and contents -->
> </x>

> Here, the inline comment suggests that the element 'x' now lies within
> the 'edi' namespace.

So it does, in the sense that the scope of the "edi:' prefix is the
element "x".  But the name "x" is not defaulted to the edi namespace;
it would have to be "edi:x" for that, or the edi namespace would
have to also be the default namespace through the presence of
an "xmlns='http://ecommerce.org/schema'" attribute.

Instead the namespace of "x" is the current default namespace if any,
or no namespace if there is no current default.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Thu Nov  5 22:45:47 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:17 2004
Subject: Namespaces - defaulting question (re:WD-xml-names19980916)
Message-ID: <3.0.32.19981105144302.00b62510@pop.intergate.bc.ca>

At 02:32 PM 11/5/98 -0800, Steve Harris wrote:
>Reading the Namespaces specification, I've found contradictory examples
>of namespace defaulting. Any input in determining the proper
>interpretation would be greatly appreciated.
>  The first example is as follows:
><?xml version="1.0"?>
>  <x xmlns:edi='http://ecommerce.org/schema'>
>  <!-- the edi namespace applies to the "x" element and contents -->
></x>

Good catch.  This comment is erroneous - the namespace only applies
to things that are prefixed "edi", which the "x" element clearly
isn't.  The comment should say that the binding of the prefix "edi"
to the URI "http://ecommerce.org/schema" appliesto the "x"
element and contents.

To be fixed. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  6 01:55:21 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:17 2004
Subject: XML Search Engine
References: <005c01be08f1$c8379920$d3228018@jabr.ne.mediaone.net> <3641C09A.746EE929@pix.com.br>
Message-ID: <36425662.70BB@hiwaay.net>

Fernando Cabral wrote:
> 
> 
> This will not be a poblem with any "decent" text retrieval engine 

This is an interesting thread and relevant to my current work which 
is unfortunatly, not in XML, but in relational implementations.  
However, can someone direct me to any sites which provide source 
examples of full text retrieval engines?  

Please reply to clbullar@ingr.com

Thanks in advance.

Len Bullard
IPS

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Fri Nov  6 02:08:47 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:17 2004
Subject: XML Search Engine
Message-ID: <3.0.32.19981105180610.00b862d0@pop.intergate.bc.ca>

At 07:52 PM 11/5/98 -0600, len bullard wrote:
>This is an interesting thread and relevant to my current work which 
>is unfortunatly, not in XML, but in relational implementations.  
>However, can someone direct me to any sites which provide source 
>examples of full text retrieval engines?  

Such sites will be rather small, due to a little problem in 
the retrieval business, namely nobody has ever made serious
money at it.  Five years ago, I would have said the leading
vendors were Fulcrum, Verity, PLS, Open Text, and IDI/Basis.

Fulcrum barely dodged bankruptcy and ended up being swallowed by
PC Docs, a low-end document management company.  Verity is the only
one still soldiering on, having burned through $30M in venture cap
and a large part of their IPO bucks, are actually showing some
signs of small amounts of black ink.  PLS staggered (mostly) into
the arms of AOL.  Open Text retreated from search into document
management, and bought IDI.

Lesson: there's not much juice in that business. XML might cheer
things up a bit, you never know.  There are any number of decent
free search engines you can run with either Apache or NT servers...

If you're doing relational search, most relational vendors (Oracle,
Informix, etc) have some sort of full-text add-on that usually
works OK. 

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


From Jon.Bosak at eng.Sun.COM  Fri Nov  6 04:16:55 1998
From: Jon.Bosak at eng.Sun.COM (Jon Bosak)
Date: Mon Jun  7 17:06:17 2004
Subject: XML and IE5 beta PR2
Message-ID: <199811060413.UAA23811@boethius.eng.sun.com>

[Simon North:]

| For anyone who hasn't noticed, the preview 2 release of IE5 was put 
| on the public servers yesterday (it had been placed there last Friday 
| but was pulled shortly afterwards). Today, Microsoft appear to have 
| put updated documentation on the SBN web pages. 
| 
| The new release doesn't seem to support the style part of XSL, only 
| the transformation part [...]

It's my impression that Microsoft sees XSL simply as a way to do tag
transformation and that their strategy for XML display is to use XSL
to transform XML tags to HTML tags.  This means, of course, that you
will not be able to use Microsoft tools that support XSL to do any
formatting more complex than what can be expressed using HTML+CSS.

I would be delighted to learn that I have gotten the wrong impression
about this.  If anyone finds out something that contradicts this
assessment, such as a public statement of support for formatting
objects or Microsoft software that supports formatting objects, please
let me know.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Fri Nov  6 04:20:39 1998
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:06:17 2004
Subject: IE5 - Retrieving attributes from an internal entity
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C08743F7A@RED-MSG-56>

The &om; node is an ENTITYREF node which has a read-only child node called
"variable".
The "xml" property on the ENTITYREF node gives back "&om;".  If you want to
get the markup "<variable targetset='om'>OM</variable>" you have to navigate
to the "variable" child, then use the "xml" property from there.

-----Original Message-----
From: Don Kackman [mailto:DKACKMAN@agchem.com]
Sent: Monday, November 02, 1998 1:11 PM
To: 'XML Dev'
Subject: Retrieving attributes from an internal entity


Hello,

I'm using Microsoft's XML parser that comes as part of IE 5 beta 1 as a
component of an application that will use XML as its document format.
Since IE5 is still a beta I'm having some trouble determining if certain
behaviors are bugs in the current version of their parser or correctly
reflect the W3C specification.

Namely I'm using an internal entity declaration as follows:

<!ENTITY om "<variable targetset='om'>OM</variable>">

as part of the internal part of the DTD.

I can load the document into MSXML (thier parser) and traverse the node
tree. When I get to the node where I am refering to the &om; entity I
get OM back as the value of that node but I cannot retrieve the
targetset attribute.

It is my understanding that internal entities should be parsed in place
when they are refered to, which should mean that I can treat that node
as I would any other. This does not seem to be the case with the MS
parser.

Is this a limitation of the MS beta parser or am I misunderstanding how
entities are used in XML?

Thank you,

Don Kackman
dkackman@agchem.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jswleung at hkbu.edu.hk  Fri Nov  6 04:33:09 1998
From: jswleung at hkbu.edu.hk (Josef Siu-wai Leung)
Date: Mon Jun  7 17:06:17 2004
Subject: XML and IE5 beta PR2
In-Reply-To: <199811060413.UAA23811@boethius.eng.sun.com>
Message-ID: <Pine.A41.3.96.981106121813.17086C-100000@net1.hkbu.edu.hk>


On Thu, 5 Nov 1998, Jon Bosak wrote:

> It's my impression that Microsoft sees XSL simply as a way to do tag
> transformation and that their strategy for XML display is to use XSL
> to transform XML tags to HTML tags.  This means, of course, that you
> will not be able to use Microsoft tools that support XSL to do any
> formatting more complex than what can be expressed using HTML+CSS.

I find the same in this beta version. And I would like to know which is
the most XSL compliant browser at the moment.  Any advice? 

Josef



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From avirr at LanMinds.Com  Fri Nov  6 05:52:33 1998
From: avirr at LanMinds.Com (Avi Rappoport)
Date: Mon Jun  7 17:06:17 2004
Subject: XML Search Engine
In-Reply-To: <36425662.70BB@hiwaay.net>
References: <005c01be08f1$c8379920$d3228018@jabr.ne.mediaone.net>
 <3641C09A.746EE929@pix.com.br>
Message-ID: <v04102d0cb2683cee59e8@[207.33.50.55]>

At 7:52 PM -0600 11/5/98, len bullard wrote:
> This is an interesting thread and relevant to my current work which
> is unfortunatly, not in XML, but in relational implementations.
> However, can someone direct me to any sites which provide source
> examples of full text retrieval engines?
>
> Please reply to clbullar@ingr.com

I'm replying publicly because Tim did, and I happen to know of some 
available source code:

ht:Dig <http://www.htdig.org/>
SWISH-E <http://sunsite.berkeley.edu/SWISH-E/ >
SWISH++ <http://www.best.com/~pjl/software.html>
WebGlimpse <http://donkey.CS.Arizona.EDU/webglimpse/>
ICE (Perl) <http://www.informatik.th-darmstadt.de/~neuss/ice/ice.html>
BBDBot (Java) <http://www.endware.com/bddbot/>

More info on these topics on my Web Site Search Tools site: 
<http://www.searchtools.com/>.

Avi
________________________________________________________________
Avi Rappoport, Web Site Search Tools Maven: <mailto:avirr@lanminds.com>
Guide to Site Indexing and Local 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  6 05:57:03 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:17 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML Application
In-Reply-To: <3641FCE4.61D46D15@locke.ccil.org>
References: <3641FCE4.61D46D15@locke.ccil.org>
Message-ID: <13890.36667.687028.56131@localhost.localdomain>

John Cowan writes:

 > 10. An XML processor (necessarily a non-validating one) that does
 > not include the replacement text of an external parsed entity
 > in place of an entity reference must notify the application that
 > it recognized but did not read the entity (4.4.3)  [SAX does not
 > provide for this]

SAX offloads this responsibility to the application using the
EntityResolver interface.


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


From north at Synopsys.COM  Fri Nov  6 09:03:45 1998
From: north at Synopsys.COM (Simon North)
Date: Mon Jun  7 17:06:17 2004
Subject: MS and XSL (was XML and IE5 beta PR2)
In-Reply-To: <199811060413.UAA23811@boethius.eng.sun.com>
Message-ID: <199811060901.KAA23380@goofy.gr05.synopsys.com>

[Jon Bosak:]

> It's my impression that Microsoft sees XSL simply as a way to do tag
> transformation and that their strategy for XML display is to use XSL
> to transform XML tags to HTML tags.  This means, of course, that you
> will not be able to use Microsoft tools that support XSL to do any
> formatting more complex than what can be expressed using HTML+CSS.

That is more or less the impression that I took away from my 
visit to Redmond for the XML Summit in July, with a few 
qualifications. 

As I understood it, Microsoft are committed to using XML as an 
intermediate format ("islands of data"). DHTML is the display tag 
language of choice. XSL is only of interest in so far as it can be 
used to transform XML into DHTML, but XSL is not necessarily the 
language of choice because (and this is borne out by the fact the IE5 
appears to be fully DOM compliant) the DOM gives as much, if not more 
accessibility. 

It was my understanding that MS were heavily committed to CSS, but 
they intend to extend  it to support 'CSS behaviors', which 
allows executable code to be attached to elements via style sheets. 
This would promote re-usable code, would ease the 'coder 
bottleneck' that currently seems to threaten web page production 
efforts, and would introduce a form of 'no-install' software (a 
contender for Java applets?). 

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


From db at Eng.Sun.COM  Fri Nov  6 11:44:39 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:18 2004
Subject: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org> <363DE9F3.2EDF9979@eng.sun.com> <363F060D.47FB0E2C@technologist.com>
Message-ID: <3642E010.DA093709@eng.sun.com>

Paul Prescod wrote:
> David Brownell wrote:
> > To put it differently:  is there really room for another API
> > to represent XML structure?
> >
> > I tend to think that DOM, warts and all, is "good enough" for
> > most purposes.  And for those other purposes, I suspect that
> > no standard API could suit.
> 
> I find it odd that we can have "standard APIs" for the full complexity of
> relational data, and probably eventually for object database data, but it
> is perceived to be impossible to do the same for the parse tree of XML
> data. I mean it is just annotated tree structures: it shouldn't be rocket
> science (but neither is it trivial).

If it's just annotated tree structures, I'd say that's what DOM is for!
Or should be, warts and XML Data Model conformance aside.

Why would I say no "standard API" would exist for the rest?  There are
thousands (conservatively!) of data/object models specialized to each
application.  While a tree (or grove, or graph) would seem isomorphic
with any such model, it's not necessarily optimal for any one of them.

Similarly, "pure data" is a model many of us have been moving folk away
from over the last decade.  It's critical for interoperability between
system components (e.g. over the web, with XML!), but raw data must be
joined with methods (or other code) before it's used.  Ergo, "objects"
instead of APIs to data; classes not structs. 

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


From fernando at pix.com.br  Fri Nov  6 12:15:56 1998
From: fernando at pix.com.br (Fernando Cabral)
Date: Mon Jun  7 17:06:18 2004
Subject: XML Search Engine
References: <3.0.32.19981105180610.00b862d0@pop.intergate.bc.ca>
Message-ID: <3642A141.5B2D3EE0@pix.com.br>

Tim Bray wrote:

> Such sites will be rather small, due to a little problem in
> the retrieval business, namely nobody has ever made serious
> money at it.  Five years ago, I would have said the leading
> vendors were Fulcrum, Verity, PLS, Open Text, and IDI/Basis.
>

Fulcrum has had its moment of glory. The same can not be saidabout the others.
Nevertheless, you've forgotten a very
important name: Dataware Technologies (http://www.dataware.com).

Dataware grew from 0 to several million dollars in a few years
selling text-retrieval systems for CDs (about $40MB/year). Then
it bought BRS, with more than 2,000 data centers.

BRS is still the leading product in text retrieval on a variety
of platforms. Just to mention libraries alone, there are more
than 200 big, big libraries using BRS.

About two years ago Dataware launched EPMS, now renamed
Dataware II Publisher. This is a version of BRS entirely based
on SGML (it reads from about 300 different formats, converts
and stores as an SGML file, and allows you to do text retrieval
both in the traditional way as well as in a more SGML-like way.

Of course, it can read and index directly SGML, XML and HTML.

> Lesson: there's not much juice in that business. XML might cheer
> things up a bit, you never know.  There are any number of decent
> free search engines you can run with either Apache or NT servers...
>

Talking about money, it is quite clear that IBM made a lotof money selling
STAIRS. Now it is musty but for more
than 20 years it reigned undisputed undisputed in the mainframe
kingdom.

So, I think the right conclusion is that in the low-end line of products
where quality/functionality is disputable and price is very low
(PC DOCs, Verity...) there is no real money. On the other hand,
vendors aiming the high-end market should not complain.

> If you're doing relational search, most relational vendors (Oracle,
> Informix, etc) have some sort of full-text add-on that usually
> works OK.

Own experience is that relational vendors are complete uncapableof providing a
good solution for text retrieval. The products
are usually very poor on the funcionality side and miserable on
the performance side.

In fact, I'd like to hear from any of you that know any SIGNIFICANT
application using any relational database for text-retrieval. By significant
I mean: a) several giga or even terabytes of text; b) several millions of
documents; c) at least a few dozens of concurrent users; d) need of
complex searchs (say 20 or 30 words/parts of words combined
with 4 or 5 different operators); d) response time bellow one second
in a common UNIX or mainframe platform.

If any of you have ever heard about such an application, I am eager
to hear about it.

- fernando

--
Fernando Cabral                         Padrao iX Sistemas Abertos
mailto:fernando@pix.com.br              http://www.pix.com.br
                                        mailto:Pix@Pix.com.br
Fone: +55 61 321-2433                   Fax: +55 61 225-3082
15? 45' 04.9" S                         47? 49' 58.6" W
19? 37' 57.0" S                         45? 17' 13.6" W



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Fri Nov  6 14:27:33 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:18 2004
Subject: Namespaces - defaulting question (re:WD-xml-names19980916)
References: <3.0.32.19981105144302.00b62510@pop.intergate.bc.ca>
Message-ID: <3643078E.F8C1B652@locke.ccil.org>

Tim Bray wrote:

> At 02:32 PM 11/5/98 -0800, Steve Harris wrote:
> >Reading the Namespaces specification, I've found contradictory examples
> >of namespace defaulting. Any input in determining the proper
> >interpretation would be greatly appreciated.
> >  The first example is as follows:
> ><?xml version="1.0"?>
> >  <x xmlns:edi='http://ecommerce.org/schema'>
> >  <!-- the edi namespace applies to the "x" element and contents -->
> ></x>
> 
> Good catch.  This comment is erroneous - the namespace only applies
> to things that are prefixed "edi", which the "x" element clearly
> isn't.

I think the comment is correct as it stands, though I agree it could
be clearer.  Element isn't element tag/GI.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Fri Nov  6 14:55:01 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:18 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML Application
References: <3641FCE4.61D46D15@locke.ccil.org> <13890.36667.687028.56131@localhost.localdomain>
Message-ID: <36430DFD.2770E438@locke.ccil.org>

david@megginson.com wrote:

>  > 10. An XML processor (necessarily a non-validating one) that does
>  > not include the replacement text of an external parsed entity
>  > in place of an entity reference must notify the application that
>  > it recognized but did not read the entity (4.4.3)  [SAX does not
>  > provide for this]
> 
> SAX offloads this responsibility to the application using the
> EntityResolver interface.

But there's no way for the application to tell the parser
"Don't read this entity."  Returning an InputSource on the null
string is similar, but not identical, in effect.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From anette.engel at crpht.lu  Fri Nov  6 15:37:26 1998
From: anette.engel at crpht.lu (anette.engel@crpht.lu)
Date: Mon Jun  7 17:06:18 2004
Subject: Storing XML documents in an OODB
Message-ID: <C12566B4.00547810.00@mmfileserver.crpht.lu>

I want to write a Java- application which stores and retrieves XML
documents
in/from an object-oriented Database (Object-Store).  I already had a closer
look
to Sun's package and to documentation provided by ObjectStore.
Nevertheless I am not yet sure how to store/retrieve XML documents in the
OODB.
Do I have to wrrite my own document class or can I take advantage of
existing
implemtations? Does anyone know of some interesting web-sites which cover
similar problems?

Regards

Anette Engel



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From pbutkiew at banta-im.com  Fri Nov  6 16:10:34 1998
From: pbutkiew at banta-im.com (Paul Butkiewicz)
Date: Mon Jun  7 17:06:18 2004
Subject: Storing XML documents in an OODB
In-Reply-To: <C12566B4.00547810.00@mmfileserver.crpht.lu>
Message-ID: <000701be099f$cafe0e10$6e34ccd0@scriabin.dcm.com>

I don't have any direct experience with Object Store, but for what it's
worth I do have a fair amount of background using Versant's OODB with Java.
With Versant, non-serialized persistent objects must extend other persistent
objects, so you might have some difficulty trying to use third party
objects.  Versant provides a post-processor that takes .class files and
modifies them to be persistent and you might be able to use that on a third
party class library, but some functionality may require vendor- or
OMG-specific collection classes or an intimacy with you XML implementation
classes themselves (for example, do you want to search on these objects?).
And then there's the pesky details --- if an internal function in a closed
implementation dereferences a now-persistent object expecting it to be
garbage collected by Java, now the dereferenced object will hang around the
database taking up space.

Anyway, I would recommend finding an open-source implementation that you can
tweak to work with Object Store, waiting for Object Store or a third party
to release a DOM implementation or whatever, or find someone otherwise
willing to share their source for you to tweak.  I probably fall into that
last category, but my code isn't quite ready for prime time yet.  :)

Paul Butkiewicz
arabbit@earthlink.net

-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
anette.engel@crpht.lu
Sent: Friday, November 06, 1998 10:33 AM
To: xml-dev@ic.ac.uk
Subject: Storing XML documents in an OODB


I want to write a Java- application which stores and retrieves XML
documents
in/from an object-oriented Database (Object-Store).  I already had a closer
look
to Sun's package and to documentation provided by ObjectStore.
Nevertheless I am not yet sure how to store/retrieve XML documents in the
OODB.
Do I have to wrrite my own document class or can I take advantage of
existing
implemtations? Does anyone know of some interesting web-sites which cover
similar problems?

Regards

Anette Engel



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Fri Nov  6 16:24:49 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:18 2004
Subject: XML Search Engine
Message-ID: <3.0.32.19981106075715.00b71540@pop.intergate.bc.ca>

At 10:12 AM 11/6/98 +0200, Fernando Cabral wrote:
>Nevertheless, you've forgotten a very
>important name: Dataware Technologies (http://www.dataware.com).
>
>Dataware grew from 0 to several million dollars in a few years
>selling text-retrieval systems for CDs (about $40MB/year). Then
>it bought BRS, with more than 2,000 data centers.

Well, I just went and checked their financials, and while they
actually showed a bit of profit I observe that their revenue, 
for this quarter against the same quarter last year, is declining 
(down from $5.4m to $4.8m) and the 3/4 results are down from $14.6m 
to $14.2m.  This is the high-growth Internet/Software field?  I repeat 
my claim that this is not a good busines to be in.

>About two years ago Dataware launched EPMS, now renamed
>Dataware II Publisher. This is a version of BRS entirely based
>on SGML (it reads from about 300 different formats, converts
>and stores as an SGML file, and allows you to do text retrieval
>both in the traditional way as well as in a more SGML-like way.
>
>Of course, it can read and index directly SGML, XML and HTML.

Can anyone else substantiate this?  Last time I looked at BRS/search,
it was a very traditional atomic-document thing; it had some fielded
search, but it could only *find* documents.  Obviously for XML you
need to find elements.  It would be great if BRS was really 
SGML/XML-savvy.

>Talking about money, it is quite clear that IBM made a lotof money selling
>STAIRS. Now it is musty but for more
>than 20 years it reigned undisputed undisputed in the mainframe
>kingdom.

Here we agree.  IBM made some serious money with STAIRS (I suspect
mostly by selling mainframes to run it on).

>So, I think the right conclusion is that in the low-end line of products
>where quality/functionality is disputable and price is very low
>(PC DOCs, Verity...) there is no real money. On the other hand,
>vendors aiming the high-end market should not complain.

I don't the evidence supports this view.

>Own experience is that relational vendors are complete uncapableof providing a
>good solution for text retrieval. The products
>are usually very poor on the funcionality side and miserable on
>the performance side.

That's really interesting information.  This is about the 5th time
I've heard this; always anecdotal evidence, but it adds up. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  6 19:21:49 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:18 2004
Subject: XML Search Engine
References: <3.0.32.19981105180610.00b862d0@pop.intergate.bc.ca> <3642A141.5B2D3EE0@pix.com.br>
Message-ID: <36434AF0.FA7400B3@infinet.com>

Fernando Cabral wrote:

> Tim Bray wrote:
>
> > Such sites will be rather small, due to a little problem in
> > the retrieval business, namely nobody has ever made serious
> > money at it.  Five years ago, I would have said the leading
> > vendors were Fulcrum, Verity, PLS, Open Text, and IDI/Basis.
> >
>
> Fulcrum has had its moment of glory. The same can not be saidabout the others.
> Nevertheless, you've forgotten a very
> important name: Dataware Technologies (http://www.dataware.com).
>
> Dataware grew from 0 to several million dollars in a few years
> selling text-retrieval systems for CDs (about $40MB/year). Then
> it bought BRS, with more than 2,000 data centers.
>
> BRS is still the leading product in text retrieval on a variety
> of platforms. Just to mention libraries alone, there are more
> than 200 big, big libraries using BRS.
>
> About two years ago Dataware launched EPMS, now renamed
> Dataware II Publisher. This is a version of BRS entirely based
> on SGML (it reads from about 300 different formats, converts
> and stores as an SGML file, and allows you to do text retrieval
> both in the traditional way as well as in a more SGML-like way.
>
> Of course, it can read and index directly SGML, XML and HTML.
>
> > Lesson: there's not much juice in that business. XML might cheer
> > things up a bit, you never know.  There are any number of decent
> > free search engines you can run with either Apache or NT servers...
> >
>
> Talking about money, it is quite clear that IBM made a lotof money selling
> STAIRS. Now it is musty but for more
> than 20 years it reigned undisputed undisputed in the mainframe
> kingdom.
>
> So, I think the right conclusion is that in the low-end line of products
> where quality/functionality is disputable and price is very low
> (PC DOCs, Verity...) there is no real money. On the other hand,
> vendors aiming the high-end market should not complain.
>
> > If you're doing relational search, most relational vendors (Oracle,
> > Informix, etc) have some sort of full-text add-on that usually
> > works OK.
>
> Own experience is that relational vendors are complete uncapableof providing a
> good solution for text retrieval. The products
> are usually very poor on the funcionality side and miserable on
> the performance side.
>
> In fact, I'd like to hear from any of you that know any SIGNIFICANT
> application using any relational database for text-retrieval. By significant
> I mean: a) several giga or even terabytes of text; b) several millions of
> documents; c) at least a few dozens of concurrent users; d) need of
> complex searchs (say 20 or 30 words/parts of words combined
> with 4 or 5 different operators); d) response time bellow one second
> in a common UNIX or mainframe platform.
>
> If any of you have ever heard about such an application, I am eager
> to hear about it.

I have heard that CONText from Oracle was pretty good.  I am not sure about its
performance though, but Oracle used to make a huge deal about this "cartridge" a
while back.

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


From 106551.310 at compuserve.com  Fri Nov  6 20:32:19 1998
From: 106551.310 at compuserve.com (Ted Carroll & Claire Samson)
Date: Mon Jun  7 17:06:18 2004
Subject: XML for resource scheduling / calender management
Message-ID: <199811061530_MC2-5F5F-A23B@compuserve.com>

I've been interested in software for scheduling groups of resources,
such as staff members within a workgroup, organising meeting rooms
within a company or booking equipment - as a way of producing a 'virtual'
office wall planner'.  I've developed a multi-user program for this 
type of activity and have also developed a free-standing viewer for 
displaying a virtual 'wall planner' file.  This uses XML - XML
provides a good way of formating fairly complex data of this type.
XML is also used to allow remote updates to the schedule - i.e. a 
remote request to book a room could be made using a small applet 
that sends a message in the appropriate XML format.

I would be interested to know if anyone on the list is aware of
any other developments in the use of XML for diary information
such as maintaining shared calendars/scheduling information.  I am 
sure there is a huge potential for an open format based on XML.  

The free software (both the multi-user program and the XML-based 
'wall planner' viewer can be downloaded from www.screenplan.com  

(It's Windows 95/98/NT at the moment - a Java viewer may follow!)

J.C.Samson

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From boblyons at unidex.com  Fri Nov  6 20:38:23 1998
From: boblyons at unidex.com (Robert C. Lyons)
Date: Mon Jun  7 17:06:18 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML Application
Message-ID: <01BE099B.0F2A64D0@cc398234-a.etntwn1.nj.home.com>

John,

This list is very helpful. Thanks.

I noticed some minor typos.
List item #3 should be changed to the following (the changes are in bold):

3.  An XML processor must pass the single character &#xA; in place
of &#xD; or &#xD;&#xA; appearing in its input. (2.11)

Bob

------
Bob Lyons
EC Consultant
Unidex Inc.
1-732-975-9877
Fax: 1-732-975-9866
boblyons(at)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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From fernando at pix.com.br  Fri Nov  6 20:46:23 1998
From: fernando at pix.com.br (Fernando Cabral)
Date: Mon Jun  7 17:06:18 2004
Subject: XML Search Engine
References: <3.0.32.19981105180610.00b862d0@pop.intergate.bc.ca> <3642A141.5B2D3EE0@pix.com.br> <36434AF0.FA7400B3@infinet.com>
Message-ID: <36431886.99A2F1F8@pix.com.br>



Tyler Baker wrote:

> I have heard that CONText from Oracle was pretty good.  I am not sure about its
> performance though, but Oracle used to make a huge deal about this "cartridge" a
> while back.

Oracle has had several different names for this product (SQL-TEXT, CONText,
TextServer).
No matter what the name is, it still does work well. At least I've never been able
to see
a single good application at work. In fact, even some very simple applications
have lots of flaws.

- fernando


--
Fernando Cabral                         Padrao iX Sistemas Abertos
mailto:fernando@pix.com.br              http://www.pix.com.br
                                        mailto:Pix@Pix.com.br
Fone: +55 61 321-2433                   Fax: +55 61 225-3082
15? 45' 04.9" S                         47? 49' 58.6" W
19? 37' 57.0" S                         45? 17' 13.6" W



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From estephen at appliedtheory.com  Fri Nov  6 22:10:10 1998
From: estephen at appliedtheory.com (Eric A. Stephens)
Date: Mon Jun  7 17:06:18 2004
Subject: Announcing the XML-HR Initiative - www.xml-hr.org
Message-ID: <Pine.LNX.4.03.9811061616540.3166-100000@javaboy.appliedtheory.com>

In partnership with AppliedTheory Communications (www.appliedtheory.com),
the America's Job Bank Service Center (www.ajb.dni.us) announces the
XML-HR Initiative.

The purpose of the initiative is to collaborate on the creation and
standardization of human resource/electronic recruiting XML definitions.
These definitions (DTDs) can be used in Internet/Intranet applications and
the exchange of such data between disparate systems. 

Upcoming releases of AJB will rely heavily on XML definitions for both
internal and external data exchange between processes and applications.

Those interested in this initiative are encouraged to subscribe to one of
the e-mail lists described on the web page (www.xml-hr.org).

Eric A. Stephens                      estephen@AppliedTheory.com
Software Engineering Group          http://www.AppliedTheory.com
AppliedTheory Communications, Inc.





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From fernando at pix.com.br  Fri Nov  6 22:18:41 1998
From: fernando at pix.com.br (Fernando Cabral)
Date: Mon Jun  7 17:06:18 2004
Subject: XML Search Engine
References: <3.0.32.19981106075715.00b71540@pop.intergate.bc.ca>
Message-ID: <3642FED8.6183FFD8@pix.com.br>

Tim Bray wrote:

> Well, I just went and checked their financials, and while they
> actually showed a bit of profit I observe that their revenue,
> for this quarter against the same quarter last year, is declining
> (down from $5.4m to $4.8m) and the 3/4 results are down from $14.6m
> to $14.2m.  This is the high-growth Internet/Software field?  I repeat
> my claim that this is not a good busines to be in.
>

Perhaps because they have been investing a lot in a newproduct named KMS (Knowledge
Management Suite) and
kind of forgetting BRS itself.

> >About two years ago Dataware launched EPMS, now renamed
> >Dataware II Publisher. This is a version of BRS entirely based
> >on SGML (it reads from about 300 different formats, converts
> >and stores as an SGML file, and allows you to do text retrieval
> >both in the traditional way as well as in a more SGML-like way.
> >
> >Of course, it can read and index directly SGML, XML and HTML.
>
> Can anyone else substantiate this?  Last time I looked at BRS/search,
> it was a very traditional atomic-document thing; it had some fielded
> search, but it could only *find* documents.  Obviously for XML you
> need to find elements.  It would be great if BRS was really
> SGML/XML-savvy.

Perhaps you should read again what I said. The product is not BRS/Search,it is
Dataware II Publisher (formely EPMS). It is a "version"  of BRS
because it uses pretty much the same basic technology. On the other
hand, it is entirely different because the internal format is SGML,
so it allows for searchs in the SGML style (as opposed to "paragraph"
qualification). As the manual says (page 136): "You can search your
publication by SGML element tags. For example, you
can search your publications by the TITLE element".

You can also design style sheets based on the SGML tags for printing
and displaying purposes. BRS itself does not know anything about
SGML, but Dataware II Publisher certainly does. I have been using
the product for several months now. I have a number of publications
in it, including some of the Shakespeare works (markup by Jon Bosak - Moby Lexical
Tools)

I am not as knowledgeable as you on SGML/XML so I can not garantee
100% compatibility with SGML. What I can say is that I like what
I have. To me it looks like what any XML user would like to
see in a search engine.

> .>Talking about money, it is quite clear that IBM made a lotof money selling
> >STAIRS. Now it is musty but for more
> >than 20 years it reigned undisputed undisputed in the mainframe
> >kingdom.
>
> Here we agree.  IBM made some serious money with STAIRS (I suspect
> mostly by selling mainframes to run it on).
>
> >So, I think the right conclusion is that in the low-end line of products
> >where quality/functionality is disputable and price is very low
> >(PC DOCs, Verity...) there is no real money. On the other hand,
> >vendors aiming the high-end market should not complain.
>
> I don't the evidence supports this view.
>
> >Own experience is that relational vendors are complete uncapableof providing a
> >good solution for text retrieval. The products
> >are usually very poor on the funcionality side and miserable on
> >the performance side.
>
> That's really interesting information.  This is about the 5th time
> I've heard this; always anecdotal evidence, but it adds up. -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/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



--
Fernando Cabral                         Padrao iX Sistemas Abertos
mailto:fernando@pix.com.br              http://www.pix.com.br
                                        mailto:Pix@Pix.com.br
Fone: +55 61 321-2433                   Fax: +55 61 225-3082
15? 45' 04.9" S                         47? 49' 58.6" W
19? 37' 57.0" S                         45? 17' 13.6" W




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ralph at fsc.fujitsu.com  Fri Nov  6 22:21:26 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:18 2004
Subject: HyBrick with English-language Menu
Message-ID: <3.0.5.32.19981107051526.009cb870@pophost.fsc.fujitsu.com>

All,

The latest version of HyBrick, V.08, with XLink/XPointer support, that I
announced a few days ago, is now available from FSC's Web site:
http://collie.fujitsu.com/hybrick/

This version has an English-language menu, but is otherwise identical to
the version on Fujitsu's Web site in Japan. I have also added some files to
the distribution to show more of HyBrick's formatting capabilities.

Best regards,

Ralph E. Ferris
Fujitsu Software Corporation (FSC)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cbullard at hiwaay.net  Sat Nov  7 00:08:44 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:19 2004
Subject: XML Search Engine
References: <3.0.32.19981105180610.00b862d0@pop.intergate.bc.ca>
Message-ID: <36438EC7.7124@hiwaay.net>

Tim Bray wrote:
> 
> Lesson: there's not much juice in that business. XML might cheer
> things up a bit, you never know.  There are any number of decent
> free search engines you can run with either Apache or NT servers...
> 
> If you're doing relational search, most relational vendors (Oracle,
> Informix, etc) have some sort of full-text add-on that usually
> works OK.

Thanks Tim.  Yes, it is hard to make any money off of any 
core technology in the computer business.  The hardware are 
toasters and the software are bread.  OTOH, folks still pay 
a stable price for well-made sandwiches, so in the content 
business, (eg, the stuff in the cells), we have to find 
ways to let them "have it their way".  Analysis is still 
a pretty good mustard.

Thanks to everyone who sent me URLs today. I very much appreciate 
it.  The reading has been most interesting.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  7 00:31:16 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:19 2004
Subject: XML Search Engine
References: <3.0.32.19981106075715.00b71540@pop.intergate.bc.ca>
Message-ID: <36439428.555E@hiwaay.net>

Tim Bray wrote:
> 
> >Own experience is that relational vendors are complete uncapableof providing a
> >good solution for text retrieval. The products
> >are usually very poor on the funcionality side and miserable on
> >the performance side.
> 
> That's really interesting information.  This is about the 5th time
> I've heard this; always anecdotal evidence, but it adds up. -Tim

It would be interesting to know why.  OTOH, there may be a market for 
add-in functionality for applications that are of smaller scale and 
tend to run locally.  It may be that as we learned from HTML, trying 
to solve the ultimate problems before going to market is a way of 
staying poor.  

In the web business, and on every list I've participated 
in, it is always difficult to get folks to consider alternative 
markets for tools and content.  For example, in VRML, there is 
an almost maniacal emphasis on the web while ignoring the CD 
market where the problems of "heavy" datatypes are evident.  
For example, any animation profits by *good sound* as can be 
provided in a wav file, the human voice, etc.  It is only 
recently that some are waking up to the potential of marrying 
rock or pop albums to innovative 3D.  Because of the need to 
rehost the art into new media every so often, there are lifecycle 
problems which open content standards help to solve just as 
markup technologies helped to solve these problems for 
long lifecycle document collections.  

Thar is life in them thar niches. :-)

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sat Nov  7 01:38:16 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:19 2004
Subject: Storing XML documents in an OODB
Message-ID: <007001be09ee$46ceffb0$0200a8c0@mdaxke.mediacity.com>

Poet has *something* related to an OODB and XML; see
http://www.poet.com/CMSoverview/
It seems to want to be both a smart file system for intranet
publishing, and be an application platform.

I'd be very curious to hear any first-hand accounts of it.

-mda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Sat Nov  7 02:12:18 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:19 2004
Subject: IE50 - XML Examples
Message-ID: <00155EDE.3096@datacard.com>

     Hi all:
     
     I have trouble with linking the following example (downloaded from 
     MicroSoft site)
     This is the link error I got:
     
     "G:\mssdk\lib\ole32.lib : fatal error LNK1106: invalid file or disk 
     full: cannot seek to 0x35cb1cf1"
     
     The two files: "mshtml.h" msxml.h" I got from Internet SDK with IE4.0
     I don't know if they are still compatible with IE5.0 and where I can
     get new "mshtml.h" msxml.h" for IE5.0.
     
     Please point me the direction,
     
     Thanks a lot,
     
     SeanN
     
     --------------------------------------
     
     //////////////////////////////////////////////////////////////////////
     //////
     // Sample1.cxx: XML Object Model Sample 1
     //--------------------------------------------------------------------
     ------
     // Copyright (c) 1998  Microsoft Corporation.  All Rights Reserved.
     //
     // THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF 
     // ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO 
     // THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A 
     // PARTICULAR PURPOSE.
     //--------------------------------------------------------------------
     ------
     //////////////////////////////////////////////////////////////////////
     //////
     
     #include <windows.h>
     #include <windowsx.h>
     #include <stdlib.h>
     #include <stdio.h>
     #include <io.h>
     #include <hlink.h>
     #include <dispex.h>
     #include "mshtml.h"
     #include "msxml.h"
     #include <winnls.h>
     
     #define CHECKHR(x) hr = x; if (FAILED(hr)) goto Cleanup;
     #define SAFERELEASE(p) if (p) {(p)->Release(); p = NULL;} else ;
     
     //////////////////////////////////////////////////////////////////////
     //////
     // Synopsis: Create an IXMLElement of type t
     //////////////////////////////////////////////////////////////////////
     //////
     IXMLElement* CreateXMLElement(IXMLDocument* pDoc, XMLELEM_TYPE t)
     {
         IXMLElement* e;
         VARIANT type;
         type.vt = VT_I4;
         V_I4(&type) = t;
         VARIANT name;
     
         name.vt = VT_BSTR;
         V_BSTR(&name) = ::SysAllocString(L"ElementNode");
         HRESULT hr = pDoc->createElement(type, name, &e);
         ::SysFreeString(V_BSTR(&name));
     
         return e;
     }
     
     //////////////////////////////////////////////////////////////////////
     //////
     // Synopsis: Create an XML Document from Scratch in memory
     //////////////////////////////////////////////////////////////////////
     //////
     HRESULT MemDocument()
     {
         IXMLDocument           *pDoc = NULL;
         IStream                *pStm = NULL;
         IPersistStreamInit     *pPSI = NULL;
         IXMLElement            *enode = NULL, *el = NULL;
         IXMLElement            *root = NULL;
         LARGE_INTEGER li = {0, 0};
         HRESULT hr = S_OK;
         int i, j;
     
         // Create an empty XML document
         CHECKHR(CoCreateInstance(CLSID_XMLDocument, NULL, 
     CLSCTX_INPROC_SERVER,
                                     IID_IXMLDocument, (void**)&pDoc));
     
         // Query the IPersistStreamInit interface
         CHECKHR(pDoc->QueryInterface(IID_IPersistStreamInit, (void 
     **)&pPSI));
     
         // Create an IStream
         CHECKHR(CreateStreamOnHGlobal(NULL, TRUE, &pStm));
         pStm->AddRef();
     
         //
         // Create an xml document with a root element
         //
         ULONG ulWritten;
         CHECKHR(pStm->Write("<root/>", strlen("<root/>"), &ulWritten));
        
         // load the xml document
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL));
         CHECKHR(pPSI->Load(pStm));
     
         // get root element
         CHECKHR(pDoc->get_root(&root));
     
         //
         // Create an xml document in memory
         //
         for (i = 10; i > 0; i--)
         {
             enode = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT);
             CHECKHR(root->addChild(enode, -1, -1));
     
             for (j = 10; j > 0; j--)
             {
                 el = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT);
                 CHECKHR(enode->addChild(el, -1, -1));
                 SAFERELEASE(el);
             }
             SAFERELEASE(enode);
         }
     
     
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL));
         CHECKHR(pPSI->Save(pStm, TRUE));
     
         //
         // Load the document from the in-memory stream
         //
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL));
         CHECKHR(pPSI->Load(pStm));
     
     Cleanup:
     
         SAFERELEASE(root);
         SAFERELEASE(el);
         SAFERELEASE(enode);
         SAFERELEASE(pPSI);
         SAFERELEASE(pStm);
         SAFERELEASE(pDoc);
     
         return hr;
     }
     
     int _cdecl 
     main(int argc, char *argv[])
     {
         HRESULT hr = S_OK;
     
         CoInitialize(NULL);
     
         hr = MemDocument();
     
         CoUninitialize();
     
     
         return hr == 0 ? 0 : 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From amitr at abinfosys.com  Sat Nov  7 05:16:07 1998
From: amitr at abinfosys.com (Amit Rekhi)
Date: Mon Jun  7 17:06:19 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <003b01be0a0d$1af72650$0c01a8c0@abiwebserver.abinfosys.com>

 I have gone through the latest XML NameSpaces Draft , but I have not been able to figure out the complete behaviour of XML NameSpace software and so the ques. below.

Hello,
            I am confused as to how XML NameSpace aware processors would process:- 

            - Namespace definations (eg. xmlns:edi = "http://www.my.org/directory")
            - Nameprefixes present in XML files (eg. <edi:Segment>)

            Looking at the "xmlns" attribute value (the NameSpace Name) it is difficult to say what it signifies.eg. 
    
            * xmlns:validate  #FIXED "http://www.org/directory" - points to a directory of say validating programs, let's say a set of DLLs.

            * xmlns:xsl  #FIXED "www.w3c.org/TR/WD-xsl"  - points to the new XSL specification.

            How would an XML NS processor know what each NameSpace Name points to?
            Or is there some kind of hardcoding done in the processor which tells it what each NameSpace Name means?
 eg. if "www.w3c.org/TR/WD-xsl" is encountered , it means the XSL spec.

            What happens when an element name prefixed with a NS prefix is encountered? How does the XML NS processor process such names?
 eg.
 Let's say I have an xml file :-

<?xml version="1.0"?>
<Root xmlns:ContentCheck="http://www.my.org/checkdirectory">
 <ContentCheck:Alpha>Test Data</ContentCheck:Alpha>
</Root>

Let's also assume that  http://www.my.org/checkdirectory points to a directory of validating dlls, one of which is Alpha.dll which <ContentCheck:Alpha> is supposed to refer to.

1) How would an XML NS procesor know that <ContentCheck:Alpha> is actually supposed to refer to Alpha.dll present in http://www.my.org/checkdirectory  ?

2) I being the author of my XML file know that http://www.my.org/checkdirectory refers to a directory of validating programs, but how the XML NS processor know this?


                    Thanks in advance for any answers,
                                                                                                                                    AMIT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981107/5de41dc5/attachment.htm
From papresco at technologist.com  Sun Nov  8 01:39:57 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:19 2004
Subject: APIs ... Re: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org> <363DE9F3.2EDF9979@eng.sun.com> <363F060D.47FB0E2C@technologist.com> <3642E010.DA093709@eng.sun.com>
Message-ID: <3644F4E4.300B6A55@technologist.com>

David Brownell wrote:
> 
> > I find it odd that we can have "standard APIs" for the full complexity of
> > relational data, and probably eventually for object database data, but it
> > is perceived to be impossible to do the same for the parse tree of XML
> > data. I mean it is just annotated tree structures: it shouldn't be rocket
> > science (but neither is it trivial).
> 
> If it's just annotated tree structures, I'd say that's what DOM is for!
> Or should be, warts and XML Data Model conformance aside.

That's right. If the DOM were done right, it would be what I would call a
"standard API" for XML data. It wouldn't be appropriate for the the 
abstract, arbitrarily complex data models built on top of XML. It would
be for the XML data itself. But the DOM is quite far from that. It is
geared towards scripters and is thus not general enough for the problems
I would like to solve.

> Why would I say no "standard API" would exist for the rest?  There are
> thousands (conservatively!) of data/object models specialized to each
> application.  While a tree (or grove, or graph) would seem isomorphic
> with any such model, it's not necessarily optimal for any one of them.

That's true. Similarly, a relational data model is not the only API in
every application that *uses* a relational model, but you could say that a
single relational database API (ODBC) is usually sufficient. That's all I
would hope to replicate.

> Similarly, "pure data" is a model many of us have been moving folk away
> from over the last decade.  It's critical for interoperability between
> system components (e.g. over the web, with XML!), but raw data must be
> joined with methods (or other code) before it's used.  Ergo, "objects"
> instead of APIs to data; classes not structs.

Yes, there is an impedence mismatch that must be overcome between the XML
data model and your application's data model, just as there is a mismatch
between OO programs and relational data. A standard XML-level API (or
perhaps
two, one event driven and one tree driven) would help us to overcome that, 
not perpetuate it.

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

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dave at userland.com  Sun Nov  8 04:23:40 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:19 2004
Subject: Updated: Scripting News in XML
In-Reply-To: <36407FC0.D8919AA7@technologist.com>
References: <01BE07DB.D4272500@grappa.ito.tu-darmstadt.de>
 <364077B9.AB1AA3A6@locke.ccil.org>
Message-ID: <3.0.5.32.19981107202115.00f24960@scripting.com>

A funny thing happened when MSIE5/beta 2 was shipped, people are starting
to read our website in XML. They're also finding problems, which we
corrected today. 

Here are the change notes:

http://nirvana.userland.com/tickets/changenotes/ticketReader$3

It's looking like we'll have some new examples of real XML-based content
flow to show later this week. 

Dave

--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov  8 04:35:52 1998
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:06:19 2004
Subject: IE50 - XML Examples
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C08743F9D@RED-MSG-56>

You need the IE5 SDK which you can download from:
http://www.microsoft.com/gallery/samples/download/first.htm

-----Original Message-----
From: Sung_Nguyen@datacard.com [mailto:Sung_Nguyen@datacard.com]
Sent: Friday, November 06, 1998 6:10 PM
To: Tyler Baker; Fernando Cabral
Cc: Tim Bray; len bullard; xml-dev@ic.ac.uk; Barclay Rockwood
Subject: IE50 - XML Examples


     Hi all:
     
     I have trouble with linking the following example (downloaded from 
     MicroSoft site)
     This is the link error I got:
     
     "G:\mssdk\lib\ole32.lib : fatal error LNK1106: invalid file or disk 
     full: cannot seek to 0x35cb1cf1"
     
     The two files: "mshtml.h" msxml.h" I got from Internet SDK with IE4.0
     I don't know if they are still compatible with IE5.0 and where I can
     get new "mshtml.h" msxml.h" for IE5.0.
     
     Please point me the direction,
     
     Thanks a lot,
     
     SeanN
     
     --------------------------------------
     
     //////////////////////////////////////////////////////////////////////
     //////
     // Sample1.cxx: XML Object Model Sample 1
     //--------------------------------------------------------------------
     ------
     // Copyright (c) 1998  Microsoft Corporation.  All Rights Reserved.
     //
     // THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF 
     // ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO 
     // THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A 
     // PARTICULAR PURPOSE.
     //--------------------------------------------------------------------
     ------
     //////////////////////////////////////////////////////////////////////
     //////
     
     #include <windows.h>
     #include <windowsx.h>
     #include <stdlib.h>
     #include <stdio.h>
     #include <io.h>
     #include <hlink.h>
     #include <dispex.h>
     #include "mshtml.h"
     #include "msxml.h"
     #include <winnls.h>
     
     #define CHECKHR(x) hr = x; if (FAILED(hr)) goto Cleanup;
     #define SAFERELEASE(p) if (p) {(p)->Release(); p = NULL;} else ;
     
     //////////////////////////////////////////////////////////////////////
     //////
     // Synopsis: Create an IXMLElement of type t
     //////////////////////////////////////////////////////////////////////
     //////
     IXMLElement* CreateXMLElement(IXMLDocument* pDoc, XMLELEM_TYPE t)
     {
         IXMLElement* e;
         VARIANT type;
         type.vt = VT_I4;
         V_I4(&type) = t;
         VARIANT name;
     
         name.vt = VT_BSTR;
         V_BSTR(&name) = ::SysAllocString(L"ElementNode");
         HRESULT hr = pDoc->createElement(type, name, &e);
         ::SysFreeString(V_BSTR(&name));
     
         return e;
     }
     
     //////////////////////////////////////////////////////////////////////
     //////
     // Synopsis: Create an XML Document from Scratch in memory
     //////////////////////////////////////////////////////////////////////
     //////
     HRESULT MemDocument()
     {
         IXMLDocument           *pDoc = NULL;
         IStream                *pStm = NULL;
         IPersistStreamInit     *pPSI = NULL;
         IXMLElement            *enode = NULL, *el = NULL;
         IXMLElement            *root = NULL;
         LARGE_INTEGER li = {0, 0};
         HRESULT hr = S_OK;
         int i, j;
     
         // Create an empty XML document
         CHECKHR(CoCreateInstance(CLSID_XMLDocument, NULL, 
     CLSCTX_INPROC_SERVER,
                                     IID_IXMLDocument, (void**)&pDoc));
     
         // Query the IPersistStreamInit interface
         CHECKHR(pDoc->QueryInterface(IID_IPersistStreamInit, (void 
     **)&pPSI));
     
         // Create an IStream
         CHECKHR(CreateStreamOnHGlobal(NULL, TRUE, &pStm));
         pStm->AddRef();
     
         //
         // Create an xml document with a root element
         //
         ULONG ulWritten;
         CHECKHR(pStm->Write("<root/>", strlen("<root/>"), &ulWritten));
        
         // load the xml document
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL));
         CHECKHR(pPSI->Load(pStm));
     
         // get root element
         CHECKHR(pDoc->get_root(&root));
     
         //
         // Create an xml document in memory
         //
         for (i = 10; i > 0; i--)
         {
             enode = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT);
             CHECKHR(root->addChild(enode, -1, -1));
     
             for (j = 10; j > 0; j--)
             {
                 el = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT);
                 CHECKHR(enode->addChild(el, -1, -1));
                 SAFERELEASE(el);
             }
             SAFERELEASE(enode);
         }
     
     
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL));
         CHECKHR(pPSI->Save(pStm, TRUE));
     
         //
         // Load the document from the in-memory stream
         //
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL));
         CHECKHR(pPSI->Load(pStm));
     
     Cleanup:
     
         SAFERELEASE(root);
         SAFERELEASE(el);
         SAFERELEASE(enode);
         SAFERELEASE(pPSI);
         SAFERELEASE(pStm);
         SAFERELEASE(pDoc);
     
         return hr;
     }
     
     int _cdecl 
     main(int argc, char *argv[])
     {
         HRESULT hr = S_OK;
     
         CoInitialize(NULL);
     
         hr = MemDocument();
     
         CoUninitialize();
     
     
         return hr == 0 ? 0 : 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From info at flosim.com  Sun Nov  8 11:31:14 1998
From: info at flosim.com (Flow Simulation)
Date: Mon Jun  7 17:06:20 2004
Subject: XML for resource scheduling / calender management
Message-ID: <01BE0B0A.FCCCA0C0@dial-247.wiredworkplace.net>

J.C.Samson wrote: 

> I would be interested to know if anyone on the list is aware of
> any other developments in the use of XML for diary information
> such as maintaining shared calendars/scheduling information.

Me too.

In January there was talk of a DTD for vCard and vCalendar.   I haven't
managed to turn up anything more about this.   Is anyone aware of such
a DTD?   There must be a large number of applications for contact and
calendaring data in XML but all I could find so far was vCard/
vCalendar and X.500.

Bill Ayers (BillA@flosim.com)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From lisarein at finetuning.com  Sun Nov  8 15:53:10 1998
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun  7 17:06:20 2004
Subject: No subject
Message-ID: <199811081548.HAA05264@emerald.oz.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov  8 17:13:23 1998
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun  7 17:06:20 2004
Subject: vcard DTD
Message-ID: <3645D4AF.920EA24C@finetuning.com>

for some reason my last post got screwed up.  I was just trying to offer
the vcard DTD that had been asked for.

http://www.ietf.org/internet-drafts/draft-dawson-vcard-xml-dtd-01.txt

It was originally posted in August - but now it looks like it was
updated October 15th.  (this and other goodies, by the way, are under
the DTD resource guide at xml.com :-)

thanks,

lisa rein

http://www.finetuning.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From mda at discerning.com  Sun Nov  8 17:38:27 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:20 2004
Subject: XML for resource scheduling / calender management
Message-ID: <02d001be0b3d$03848680$0200a8c0@mdaxke.mediacity.com>

The calendar WG page can be seen at 
http://www.imc.org/ietf-calendar/
or the ietf.org site.

They currently have a vCard-like syntax.
Interconversion with an XML syntax would not be hard,
but nor does it seem particularly critical.

They seem to be mostly working now on CAP, the protocol;
the model/syntax (iCalendar) seems stable.
I think they are still debating whether CAP will
be an HTTP extension, or use existing HTTP POST/PUT, or be a 
different protocol (like SMTP/NNTP/etc.).

-mda


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dave at userland.com  Sun Nov  8 18:19:24 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:20 2004
Subject: XMLizing Folders?
In-Reply-To: <02d001be0b3d$03848680$0200a8c0@mdaxke.mediacity.com>
Message-ID: <3.0.5.32.19981108101732.00f18b50@scripting.com>

As an experiment this morning I put together a little server component that
catches references to directories that end with .xml and returns a list of
objects contained in that directory, in XML of course. 

I've been wading thru all the spec confusion around this, and decided to
approach the problem from the other side, to find out actually how much
development work was involved. It took less than an hour to put this together.

We have a pragmatic application for this, a customer who needs a script
that checks a folder on a web server every night, to see if there are any
new files added, and to get only those files. It's a pretty basic
operation, and unless you want to go WebDAV, it's not very much work on
either the client or server.

Here's a directory you can look at thru this little server component:

http://nirvana.userland.com/misc/rel200.xml

Now I'll hear a crashing loud noise about namespaces and where's my DTD and
all that stuff. The point is, there should be a DTD for this type of
object. They appear on all of our computers, they're called folders.
Where's the XML spec for folders?

Dave



--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov  8 18:28:24 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:20 2004
Subject: vcard DTD
Message-ID: <02f901be0b44$7ba8e320$0200a8c0@mdaxke.mediacity.com>

>for some reason my last post got screwed up.  I was just trying to offer
>the vcard DTD that had been asked for.
>http://www.ietf.org/internet-drafts/draft-dawson-vcard-xml-dtd-01.txt

I think the poster was looking for vCalendar (now iCalendar), and to
my knowledge that hasn't been absorbed into the xml borg yet. The
representational power and syntax of vCard is very similar however,
so I'm sure the approach could be the same: parameters are mapped
to XML attributes, and structured values with positional components
(like a postal address) are given subelement names.

I'm not yet to the point where i can speed-read DTDs, so I'm not
sure how they are handling the vCard "type-grouping" capability,
nor what happens when the value is actually kept in a vCard "VALUE" parameter,
nor what they do with "<" or "&" in a vCard value or parameter.
There's also a proposed vCard 3 extension for better handling of
language; that should probably be mapped to some general xml facility (xml:lang?).
I suspect there are some white space issues in there too, but
I always get confused by white space discussions in XML, and this
is a weekend :).

-mda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dave at userland.com  Sun Nov  8 19:45:59 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:20 2004
Subject: XMLizing Folders?
In-Reply-To: <3.0.5.32.19981108101732.00f18b50@scripting.com>
References: <02d001be0b3d$03848680$0200a8c0@mdaxke.mediacity.com>
Message-ID: <3.0.5.32.19981108114504.00f1bdc0@scripting.com>

Here's a listing of a client script that builds on this XML interface:

http://nirvana.userland.com/tickets/samples/ticketLister$14

And an explanation:

http://nirvana.userland.com/tickets/samples/ticketReader$14

Dave


--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  8 19:49:38 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:20 2004
Subject: XMLizing Folders?
Message-ID: <3.0.32.19981108114838.00b2d100@pop.intergate.bc.ca>

At 10:17 AM 11/8/98 -0800, Dave Winer wrote:
>http://nirvana.userland.com/misc/rel200.xml
>
>Now I'll hear a crashing loud noise about namespaces and where's my DTD and
>all that stuff. The point is, there should be a DTD for this type of
>object.

It's not obvious at all to me how a DTD would be useful in this app.  On 
the other hand, a stylesheet would be real nice. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Sun Nov  8 23:19:24 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:20 2004
Subject: vcard DTD
References: <02f901be0b44$7ba8e320$0200a8c0@mdaxke.mediacity.com>
Message-ID: <364625D9.47914EB8@eng.sun.com>

"Mark D. Anderson" wrote:
> 
> nor what happens when the value is actually kept in a vCard "VALUE" parameter,
> nor what they do with "<" or "&" in a vCard value or parameter.

So what's the issue here?  Dave Winer mentioned a similar issue
that forced him to encode some text in "base64" ...

Are XML-emitting tools just being incorrect?  "<" in text should
always be encoded as "&lt;" (it'll be un-encoded during parsing),
and "&" as "&amp;" (ditto).

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


From db at Eng.Sun.COM  Sun Nov  8 23:27:00 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:20 2004
Subject: XMLizing Folders?
References: <3.0.32.19981108114838.00b2d100@pop.intergate.bc.ca>
Message-ID: <36462789.95AE9086@eng.sun.com>

Tim Bray wrote:
> 
> At 10:17 AM 11/8/98 -0800, Dave Winer wrote:
> >http://nirvana.userland.com/misc/rel200.xml
> >
> >Now I'll hear a crashing loud noise about namespaces and where's my DTD and
> >all that stuff. The point is, there should be a DTD for this type of
> >object.
> 
> It's not obvious at all to me how a DTD would be useful in this app.  On
> the other hand, a stylesheet would be real nice. -Tim

Actually, I think a DTD could be very useful.  The issue is that most
of what goes into a "directory" is domain specific metadata; even for
files, different operating systems give very different metadata.  Is
there an Access Control List?  If so, is it POSIX?  What to do with
the entries?  What, no "hard link count"?  Is case significant?  Etc.

Conclusion being that there will probably be a core DTD and bunches
of domain-specific addons, each with their own namespaces.

Re crashing sounds, I was thinking about the security implications.
Browsing any directory -- filesystem, name service, phone book,
employee database, database catalog, etc -- is security-sensitive.

Yep, it'd hardly take any time at all to put together a servlet that
works this way ... ;-)

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  8 23:40:13 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:20 2004
Subject: XMLizing Folders?
In-Reply-To: <36462789.95AE9086@eng.sun.com>
References: <3.0.32.19981108114838.00b2d100@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981108153910.00f34440@scripting.com>

>>Re crashing sounds, I was thinking about the security implications.
Browsing any directory -- filesystem, name service, phone book,
employee database, database catalog, etc -- is security-sensitive.

That's a server issue. The server sysop decides which resources should be
accessible this way and by whom. HTTP and specific servers already have
provisions for this, and it has zero effect on the XML used to transmit the
contents of the folder, the two are completely independent issues.

Re having a style sheet, I could see where that would be useful if you
wanted to look at these structures in a web browser, and I'm sure someone
will do one, or five people will do five, and they'll all look like an
outliner. Aside from that, I don't want to browse these things, I want
scripts to be able to walk the structures. How it displays is almost
irrelevant in that context.

I also got a thoughtful email from Alex Hopmann at Microsoft who's been
working on WebDAV, and now I have a comparison between this and what DAV is
doing, so I may see how to fit that into our framework, which was one of my
goals in doing this work, to see if it really had to be so complicated and
to see where it fits in. He says he's going to write a WebDAV tutorial, and
*that* would really be something. We need more HOWTOs in this world, fewer
specs, more working code, more things to be compatible with. I know that's
my usual story, but I still believe it's true! (We're making progress,
IE5/Beta 2 changes things quite a bit.)

Dave




--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov  8 23:44:12 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:20 2004
Subject: vcard DTD
Message-ID: <03a001be0b70$b1366f90$0200a8c0@mdaxke.mediacity.com>

>> nor what they do with "<" or "&" in a vCard value or parameter.
>
>So what's the issue here?  Dave Winer mentioned a similar issue
>that forced him to encode some text in "base64" ...
>
>Are XML-emitting tools just being incorrect?  "<" in text should
>always be encoded as "&lt;" (it'll be un-encoded during parsing),
>and "&" as "&amp;" (ditto).

I don't think there are any deep or hard issues here, and I
have no idea what tools do; my observation was about the spec --
and a spec that talks about exchange between two syntaxes (syntaces?)
should be very explicit about encoding issues. This means consideration
of the (different) sets of special characters in the two syntaxes,
and the (different) mechanisms each has for specifying 
binary encoding, character escaping, and so on.

For example, there are similar issues in reverse, if an xml-encoded
vCard had a postal address element cdata with a semi-colon in it.
These are easy to surmount, but the issues should be explicitly identified.

BTW, while substitution with &lt is certainly the simplest
approach, I could imagine scenarios where a structured xml value
for a vCard NOTE value might be a nice thing. Admittedly, I'm stretching.

-mda

p.s.: now that i think about it, transcoding a vCard also introduces
the question of what should be done with vCard PRODID. Is anyone from
vCard/iCalendar 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dave at userland.com  Mon Nov  9 00:32:49 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:20 2004
Subject: vcard DTD
In-Reply-To: <364625D9.47914EB8@eng.sun.com>
References: <02f901be0b44$7ba8e320$0200a8c0@mdaxke.mediacity.com>
Message-ID: <3.0.5.32.19981108163054.00f16e30@scripting.com>

>>Dave Winer mentioned a similar issue that forced him to encode some text
in "base64"

If an XML value contains a < or an & you should encode them as &lt; and
&amp;. We researched this and it was there in one of the specs. (Doug Baron
will correct me if I got this wrong). 

The situation I was writing about was truly bizarre. There were two levels
of decoding going on. First I was changing the <s to &lt;s and then they
were being transmitted thru XML-RPC, and on the receiving end the XML-RPC
server thought (as it's supposed to) that it would turn the &lt;s into <s.
Oooops. That was someone else's job (an HTML browser). 

So base64 to the rescue, keep it out of the hands of the pesky server and
get those &lt;s over to the client. 

Dave


At 03:14 PM 11/8/98 -0800, David Brownell wrote:
>"Mark D. Anderson" wrote:
>> 
>> nor what happens when the value is actually kept in a vCard "VALUE"
parameter,
>> nor what they do with "<" or "&" in a vCard value or parameter.
>
>So what's the issue here?   ...
>
>Are XML-emitting tools just being incorrect?  "<" in text should
>always be encoded as "&lt;" (it'll be un-encoded during parsing),
>and "&" as "&amp;" (ditto).
>
>- 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/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>
>

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


From M.H.Kay at eng.icl.co.uk  Mon Nov  9 09:30:53 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:20 2004
Subject: Storing XML documents in an OODB
Message-ID: <001f01be0bc3$09e7d870$7008e391@bra01wmhkay.bra01.icl.co.uk>

>I want to write a Java- application which stores and retrieves XML
>documents in/from an object-oriented Database (Object-Store)

This is quite feasible to do, we have done similar things with the Jasmine
database. But a word of warning: if you do it mechanistically (each DOM
object becomes one database object) you will probably get poor performance.
You need to ask whether you really need to store data at this level of
granularity. If you generally end up retrieving most of the original
document, you would probably be better off to store the original XML as a
string and re-parse it. At any rate, do some experiments before you commit
yourself too far.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov  9 09:56:17 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:20 2004
Subject: XML Search Engine
Message-ID: <002701be0bc6$9f347d40$7008e391@bra01wmhkay.bra01.icl.co.uk>

Tim Bray:
>Can anyone else substantiate this?  Last time I looked at BRS/search,
>it was a very traditional atomic-document thing; it had some fielded
>search, but it could only *find* documents.  Obviously for XML you
>need to find elements.

Not obvious at all. Search engines have always primarily been in the
business of finding documents, I can't see why XML changes this. Of course
it is necessary to present the search engine with "documents" at an
appropriate level of granularity, which is not necessarily the original XML
source document; a filter can do this.

>>Own experience is that relational vendors are completely uncapable of
providing a
>>good solution for text retrieval.

My view is that the relational products are quite useful in hybrid
environments, where the data is mostly structured but includes some lengthy
text fields, e.g. product descriptions in a product database. Their main
limitation is that they take a strictly boolean view of the world: as with
SQL, each record is either a match or it isn't. That's been discredited in
information retrieval research for 25 years, though it is still found in
many products, especially at the low end of the market.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ssahuc at netaway.com  Mon Nov  9 10:59:45 1998
From: ssahuc at netaway.com (Sebastien Sahuc)
Date: Mon Jun  7 17:06:20 2004
Subject: XML and Internationalization...
Message-ID: <008501be0bcf$d11e43f0$10c809c0@corba.netaway>

Hi there,

I wonder if there is any specifications available in making XML documents
multilingual.

For instance, I have a xml document that specifies some operations available
to the user (the selection of the operation to call is done through a GUI).
As a small description is associated to each operation, it should be useful
to give the user this description in the custom language.

My first thought will be the following:
...
<method id="fact">

    <description lang="english">The factorial method</description>
    <description lang="french">La m?thode factorielle</description>
    <description lang="spanish">La operac?on factorial</description>

    <param id="Nbr" mode="in" type="int">
        <description lang="english">The number to pass in</description>
        <description lang="french">Le nombre ? passer</description>
        <description lang="spanish">El n?mero a calcular</description>
    </param>

</method>
...

Does anybody has a suggestion auround the syntax ? Any comment would be
greatly appreciate.

Thanks,


Sebastien SAHUC
E-mail : ssahuc@netaway.com
_______________________________________________________
NETAWAY                   Document Oriented Computing
http://www.netaway.com
6, Bd du G?n?ral Leclerc  Tel    : +33 01 55 46 95 20
92115 CLICHY CEDEX        Fax    : +33 01 55 46 95 29
FRANCE
_______________________________________________________



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Sun Nov  8 01:39:57 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:20 2004
Subject: APIs ... Re: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org> <363DE9F3.2EDF9979@eng.sun.com> <363F060D.47FB0E2C@technologist.com> <3642E010.DA093709@eng.sun.com>
Message-ID: <3644F4E4.300B6A55@technologist.com>

David Brownell wrote:
> 
> > I find it odd that we can have "standard APIs" for the full complexity of
> > relational data, and probably eventually for object database data, but it
> > is perceived to be impossible to do the same for the parse tree of XML
> > data. I mean it is just annotated tree structures: it shouldn't be rocket
> > science (but neither is it trivial).
> 
> If it's just annotated tree structures, I'd say that's what DOM is for!
> Or should be, warts and XML Data Model conformance aside.

That's right. If the DOM were done right, it would be what I would call a
"standard API" for XML data. It wouldn't be appropriate for the the 
abstract, arbitrarily complex data models built on top of XML. It would
be for the XML data itself. But the DOM is quite far from that. It is
geared towards scripters and is thus not general enough for the problems
I would like to solve.

> Why would I say no "standard API" would exist for the rest?  There are
> thousands (conservatively!) of data/object models specialized to each
> application.  While a tree (or grove, or graph) would seem isomorphic
> with any such model, it's not necessarily optimal for any one of them.

That's true. Similarly, a relational data model is not the only API in
every application that *uses* a relational model, but you could say that a
single relational database API (ODBC) is usually sufficient. That's all I
would hope to replicate.

> Similarly, "pure data" is a model many of us have been moving folk away
> from over the last decade.  It's critical for interoperability between
> system components (e.g. over the web, with XML!), but raw data must be
> joined with methods (or other code) before it's used.  Ergo, "objects"
> instead of APIs to data; classes not structs.

Yes, there is an impedence mismatch that must be overcome between the XML
data model and your application's data model, just as there is a mismatch
between OO programs and relational data. A standard XML-level API (or
perhaps
two, one event driven and one tree driven) would help us to overcome that, 
not perpetuate it.

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

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Mon Nov  9 11:35:25 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:20 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <01BE0BDC.BD3B8DE0@grappa.ito.tu-darmstadt.de>

Amit Rekhi wrote:
>            I am confused as to how XML NameSpace aware processors would process:- 
>
>            - Namespace definations (eg. xmlns:edi = "http://www.my.org/directory")
>            - Nameprefixes present in XML files (eg. <edi:Segment>)

The namespace URL does not signify anything at all.  It is not a directory, schema file, or anything else.  *All* it is is a unique identifier that identifies the namespace.  The prefix is a convenient shorthand for the full URL, nothing more.

When reading the namespace spec, it is important to understand that it tries to solve a single problem: ensuring that element and attribute names are unique.  This is significant when XML documents that use different DTDs are combined.  However, the namespace spec does no more than this.  In particular, it does not attempt to answer the problems of combining DTDs, combining instance files, or anything else.  Unique names.  That's it.  What your application does with those names is your business.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Sun Nov  8 01:39:57 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:21 2004
Subject: APIs ... Re: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org> <363DE9F3.2EDF9979@eng.sun.com> <363F060D.47FB0E2C@technologist.com> <3642E010.DA093709@eng.sun.com>
Message-ID: <3644F4E4.300B6A55@technologist.com>

David Brownell wrote:
> 
> > I find it odd that we can have "standard APIs" for the full complexity of
> > relational data, and probably eventually for object database data, but it
> > is perceived to be impossible to do the same for the parse tree of XML
> > data. I mean it is just annotated tree structures: it shouldn't be rocket
> > science (but neither is it trivial).
> 
> If it's just annotated tree structures, I'd say that's what DOM is for!
> Or should be, warts and XML Data Model conformance aside.

That's right. If the DOM were done right, it would be what I would call a
"standard API" for XML data. It wouldn't be appropriate for the the 
abstract, arbitrarily complex data models built on top of XML. It would
be for the XML data itself. But the DOM is quite far from that. It is
geared towards scripters and is thus not general enough for the problems
I would like to solve.

> Why would I say no "standard API" would exist for the rest?  There are
> thousands (conservatively!) of data/object models specialized to each
> application.  While a tree (or grove, or graph) would seem isomorphic
> with any such model, it's not necessarily optimal for any one of them.

That's true. Similarly, a relational data model is not the only API in
every application that *uses* a relational model, but you could say that a
single relational database API (ODBC) is usually sufficient. That's all I
would hope to replicate.

> Similarly, "pure data" is a model many of us have been moving folk away
> from over the last decade.  It's critical for interoperability between
> system components (e.g. over the web, with XML!), but raw data must be
> joined with methods (or other code) before it's used.  Ergo, "objects"
> instead of APIs to data; classes not structs.

Yes, there is an impedence mismatch that must be overcome between the XML
data model and your application's data model, just as there is a mismatch
between OO programs and relational data. A standard XML-level API (or
perhaps
two, one event driven and one tree driven) would help us to overcome that, 
not perpetuate it.

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

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tms at ansa.co.uk  Mon Nov  9 12:14:08 1998
From: tms at ansa.co.uk (Toby Speight)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and Internationalization...
In-Reply-To: "Sebastien Sahuc"'s message of "Mon, 9 Nov 1998 11:57:25 +0100"
References: <008501be0bcf$d11e43f0$10c809c0@corba.netaway>
Message-ID: <u1znd6p15.fsf@delivery.ansa.co.uk>

Sebastien> Sebastien Sahuc <URL:mailto:ssahuc@netaway.com>

0> In article <008501be0bcf$d11e43f0$10c809c0@corba.netaway>,
0> Sebastien wrote:

Sebastien> My first thought will be the following:
Sebastien> ...
Sebastien> <method id="fact">
Sebastien>
Sebastien>     <description lang="english">The factorial method</description>
Sebastien>     <description lang="french">La m?thode factorielle</description>
Sebastien>     <description lang="spanish">La operac?on factorial</description>
Sebastien>
Sebastien>     <param id="Nbr" mode="in" type="int">
Sebastien>         <description lang="english">The number to pass in</description>
Sebastien>         <description lang="french">Le nombre ? passer</description>
Sebastien>         <description lang="spanish">El n?mero a calcular</description>
Sebastien>     </param>
Sebastien>
Sebastien> </method>
Sebastien> ...


That's one way of doing it, though it seems to be more common to
have a separate document for each language.  The latter approach
makes it easier to add new translations with minimum disturbance
to existing work (in particular, it reduces the likelihood of
check-out conflicts in a source control system), and it means that
only the required language mappings need be copied during software
installation, reducing disk space requirements for end-users.

You might want to use the XML-defined xml:lang attribute for your
language labels, BTW, with the usual Internet language codes:
xml:lang="en-GB" or xml:lang="fr-CA".

-- 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Sun Nov  8 01:39:57 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:21 2004
Subject: APIs ... Re: CDATA by any other name... (was The raw and the cooked)
References: <f5bzpaedoc2.fsf@cogsci.ed.ac.uk> <199811011654.IAA02758@sqwest.bc.ca> <363CF738.C389AB26@technologist.com> <363DCFB4.36A59E21@locke.ccil.org> <363DE9F3.2EDF9979@eng.sun.com> <363F060D.47FB0E2C@technologist.com> <3642E010.DA093709@eng.sun.com>
Message-ID: <3644F4E4.300B6A55@technologist.com>

David Brownell wrote:
> 
> > I find it odd that we can have "standard APIs" for the full complexity of
> > relational data, and probably eventually for object database data, but it
> > is perceived to be impossible to do the same for the parse tree of XML
> > data. I mean it is just annotated tree structures: it shouldn't be rocket
> > science (but neither is it trivial).
> 
> If it's just annotated tree structures, I'd say that's what DOM is for!
> Or should be, warts and XML Data Model conformance aside.

That's right. If the DOM were done right, it would be what I would call a
"standard API" for XML data. It wouldn't be appropriate for the the 
abstract, arbitrarily complex data models built on top of XML. It would
be for the XML data itself. But the DOM is quite far from that. It is
geared towards scripters and is thus not general enough for the problems
I would like to solve.

> Why would I say no "standard API" would exist for the rest?  There are
> thousands (conservatively!) of data/object models specialized to each
> application.  While a tree (or grove, or graph) would seem isomorphic
> with any such model, it's not necessarily optimal for any one of them.

That's true. Similarly, a relational data model is not the only API in
every application that *uses* a relational model, but you could say that a
single relational database API (ODBC) is usually sufficient. That's all I
would hope to replicate.

> Similarly, "pure data" is a model many of us have been moving folk away
> from over the last decade.  It's critical for interoperability between
> system components (e.g. over the web, with XML!), but raw data must be
> joined with methods (or other code) before it's used.  Ergo, "objects"
> instead of APIs to data; classes not structs.

Yes, there is an impedence mismatch that must be overcome between the XML
data model and your application's data model, just as there is a mismatch
between OO programs and relational data. A standard XML-level API (or
perhaps
two, one event driven and one tree driven) would help us to overcome that, 
not perpetuate it.

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

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From majayg at iitk.ac.in  Mon Nov  9 12:37:28 1998
From: majayg at iitk.ac.in (Ajay Gangwar)
Date: Mon Jun  7 17:06:21 2004
Subject: Converting HTML to well formed XML
Message-ID: <001f01be0bdd$0e857da0$52a21090@cse.iitk.ernet.in>

I need to convert HTML document to well formed XML 
document. Can someone please guide me how to go
about doing this? Are any utilities available for this?

- Ajay Gangwar
  majayg@iitk.ac.in


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From richard at cogsci.ed.ac.uk  Mon Nov  9 12:56:44 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:21 2004
Subject: RXP-on-the-web now validates
Message-ID: <5273.199811091256@doyle.cogsci.ed.ac.uk>

The RXP-based XML checker at

  http://www.cogsci.ed.ac.uk/~richard/xml-check.html

now has an option to validate as well as check for well-formedness.

A few minor aspects of validity are not checked, such as PE nesting.

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


From north at Synopsys.COM  Mon Nov  9 13:19:47 1998
From: north at Synopsys.COM (Simon North)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and FrameMaker 5.5.6
Message-ID: <199811091316.OAA13053@goofy.gr05.synopsys.com>

Not a development issue, I know, but I thought it would make a 
pleasant change to be able to report something positive. 

I've been playing with FrameMaker 5.5.6 this morning, which includes 
a "Save as XML" function. The XML code it produces is well-formed and 
appears to be 100% compliant (no parse errors in most tools). 

FM outputs a CSS stylesheet (I suppose XSL would have been too much 
to ask), but the code display in IE5 Beta PR2 is very good.
 
Of course, while FM creates perfect XML code for linked images: 

<IMAGE xml:link="simple" href=" ... " show="embed" actuate="auto"/>

IE5 hasn't got a clue what to do with this.

Even cross-references are handled nicely, FrameMaker outputing code 
of this form:

<A href="document2.xml#id(78222)" xml:link="simple" 
show="replace" actuate="user" CLASS="XRef">

but again, IE5 doesn't have much of a clue what to do with this. 
Tables are also, as you could have guessed, a mess. 

Despite IE's deficiencies, FrameMaker 5.5.6 is definitely a giant 
step forward in the right direction.

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


From majayg at iitk.ac.in  Mon Nov  9 13:50:46 1998
From: majayg at iitk.ac.in (Ajay Gangwar)
Date: Mon Jun  7 17:06:21 2004
Subject: Converting HTML to well formed XML
Message-ID: <006501be0be7$78770710$52a21090@cse.iitk.ernet.in>

(I apologise if you see this twice. The first mail that I
sent was bounced back to me midway.)

I need to convert HTML document to well formed XML 
document. Can someone please guide me how to go
about doing this? Are any utilities available for this?

- Ajay Gangwar
  majayg@iitk.ac.in



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Mon Nov  9 14:05:37 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:21 2004
Subject: Converting HTML to well formed XML
In-Reply-To: <006501be0be7$78770710$52a21090@cse.iitk.ernet.in>
Message-ID: <199811091405.JAA12602@hesketh.com>

At 07:17 PM 11/9/98 +0530, Ajay Gangwar wrote:

>I need to convert HTML document to well formed XML 
>document. Can someone please guide me how to go
>about doing this? Are any utilities available for this?
>
>- Ajay Gangwar
>  majayg@iitk.ac.in

I'm in the process of converting my site (http://www.simonstl.com) to
well-formed syntax, though still using an HTML vocabulary.  I'm keeping
sort of a diary at http://www.simonstl.com/projects/html2xml/ - it lists
some helpful utilities for cleaning up the code, like Dave Raggett's TIDY,
and XML.com's RUWF well-formedness checker.

Unfortunately, no one yet (so far as I know) has created a friendly
one-step legacy HTML->well-formed XML syntax HTML converter.  That's a nice
opportunity there for some publicity, if not necessarily $$$...

Of course, if you want to to use non-HTML vocabulary, you're talking about
something much larger than syntax, and I'd recommend investing in a book -
my _XML: A Primer_, John Simpson's _Just XML_, or Elliotte Rusty Harold's
_XML: Extensible Markup Language_ to get started.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From deke at tallent.com  Mon Nov  9 14:38:11 1998
From: deke at tallent.com (Deke Smith)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and Internationalization...
Message-ID: <1301522280-41559049@tallent.com>

Sebastien Sahuc, ssahuc@netaway.com said on 11/9/98 4:57 AM:

>Hi there,
>
>I wonder if there is any specifications available in making XML documents
>multilingual.
>
>For instance, I have a xml document that specifies some operations available
>to the user (the selection of the operation to call is done through a GUI).
>As a small description is associated to each operation, it should be useful
>to give the user this description in the custom language.
>
>My first thought will be the following:
>...
><method id="fact">
>
>    <description lang="english">The factorial method</description>
>    <description lang="french">La m?thode factorielle</description>
>    <description lang="spanish">La operac?on factorial</description>
>
>    <param id="Nbr" mode="in" type="int">
>        <description lang="english">The number to pass in</description>
>        <description lang="french">Le nombre ? passer</description>
>        <description lang="spanish">El n?mero a calcular</description>
>    </param>
>
></method>
>...
>
>Does anybody has a suggestion auround the syntax ? Any comment would be
>greatly appreciate.
>

I would suggest one change to your syntax: there is a standard tag for language specification in XML. That tag is "xml:lang" and it uses ISO 639 language codes. You can find the language codes at < http://www.isoc.org:8080/langues/iso639.fr.htm>.

Your sample would look like:

...
<method id="fact">

    <description xml:lang ="en">The factorial method</description>
    <description xml:lang ="fr">La m?thode factorielle</description>
    <description xml:lang ="es">La operac?on factorial</description>

    <param id="Nbr" mode="in" type="int">
        <description xml:lang ="en">The number to pass in</description>
        <description xml:lang ="fr">Le nombre ? passer</description>
        <description xml:lang ="es">El n?mero a calcular</description>
    </param>

</method>
...

In the XML spec it talks a little bit more about language specification:
<http://www.w3.org/TR/1998/REC-xml-19980210#sec-lang-tag>

A MUCH more complicated translation format can be found from LISA at: 
<http://www.lisa.org/tmx/index.html>. This may or may not be overkill for what you are doing.


Deke


-----------------------------------------------------------------
Deke Smith
Tallent Communications Group, Brentwood TN
deke@tallent.com, 615-661-9878
-----------------------------------------------------------------
" The best way to predict the future is to invent it. " 
       - Alan Kay 



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Mon Nov  9 14:55:22 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and Internationalization...
In-Reply-To: <1301522280-41559049@tallent.com>
References: <1301522280-41559049@tallent.com>
Message-ID: <13894.65527.147246.745448@localhost.localdomain>

Deke Smith writes:

 > I would suggest one change to your syntax: there is a standard tag
 > for language specification in XML. That tag is "xml:lang" and it
 > uses ISO 639 language codes. You can find the language codes at <
 > http://www.isoc.org:8080/langues/iso639.fr.htm>.

One important point to note is that by itself, the 'xml:lang'
attribute simply indicates the language of the content and attribute
values -- it does not suggest that sibling elements with different
xml:lang values either are or are not equivalents in other languages.
For example, I could have

<itinerary>
  <city xml:lang="fr">Montr&#233;al</city>
  <city xml:lang="en">London</city>
  <city xml:lang="it">Roma</city>
</itinerary>

where the three elements are clearly not alternate versions of the
same thing.

 > <method id="fact">
 > 
 >     <description xml:lang ="en">The factorial method</description>
 >     <description xml:lang ="fr">La m?thode factorielle</description>
 >     <description xml:lang ="es">La operac?on factorial</description>
 > 
 >     <param id="Nbr" mode="in" type="int">
 >         <description xml:lang ="en">The number to pass in</description>
 >         <description xml:lang ="fr">Le nombre ? passer</description>
 >         <description xml:lang ="es">El n?mero a calcular</description>
 >     </param>
 > 
 > </method>
 > ....

This example is perfectly reasonable, as long as you remember that the
idea that the description elements represent the same thing in
different languages is derived from the document type (or vocabulary), 
not from the 'xml:lang' attribute itself.  As far as 'xml:lang' is
concerned, you could just as easily have

<description xml:lang="en">The</description>
<description xml:lang="fr">m&#233;thode</description>
<description xml:lang="es">factorial</description>

where all three make up the same description.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Mon Nov  9 16:10:25 1998
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and Internationalization...
In-Reply-To: <1301522280-41559049@tallent.com>
References: <1301522280-41559049@tallent.com>
Message-ID: <f9811091108390058@inu.menteith.com>

At 9 Nov 1998 08:30 -0600, Deke Smith wrote:
 > A MUCH more complicated translation format can be found from LISA at:
 > <http://www.lisa.org/tmx/index.html>. This may or may not be overkill for what you are doing.

While you may find concepts from the TMX work that are useful to you,
TMX stands for Translation Memory eXchange, and is concerned with
importing and exporting portions of translation memory -- phrases that
have been translated once and saved so they don't need to be
translated again -- between translation tools.  TMX has structures for
parallel portions of text in multiple languages, but there is no
concept that these chunks of text can, should, or will string together
to make a coherent "document", in anybody's sense of the word.  The
only markup in a TMX document, which is in XML, is concerned with
delimiting and identifying the parallel chunks of text for the
purposes of the translation tool: other markup from the source
document may be saved in the TMX document (with significant XML
characters escaped with entities) but only as a translation aid for
those tools that can use it.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Mon Nov  9 17:15:34 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and Internationalization...
Message-ID: <05b301be0c03$536389a0$0200a8c0@mdaxke.mediacity.com>

>One important point to note is that by itself, the 'xml:lang'
>attribute simply indicates the language of the content and attribute
>values -- it does not suggest that sibling elements with different
>xml:lang values either are or are not equivalents in other languages.
> [...]

> >     <param id="Nbr" mode="in" type="int">
> >         <description xml:lang ="en">The number to pass in</description>
> >         <description xml:lang ="fr">Le nombre ? passer</description>
> >         <description xml:lang ="es">El n?mero a calcular</description>
> >     </param>

Good point. Is there some way this could be done with XLink/XPointer,
whereby string resources could be kept externally, so that one file has this:
 <description xml:link="simple" show="embed" href="http://foo.com/mystrings#Nbr"/>
and another file (or possibly the same file) has the definitions of the string
for the different languages.

Obviously, an xml app could define whatever semantics it likes, but
i'm wondering if there is enough mechanism in the standards to do
it at parse time.

Ideally, xml:link and show could be defaulted, and the href would only
have to have the id ("#Nbr"). a binding from "above" would set xml:lang
and set the base URL for the strings file. XPointer would know to seek
out the lang=fr variant of the pointed-to resource if xml:lang was set
to "fr".

I'm sure all my specifics are screwed up, but hopefully you get the idea.

Next, I want to inline a CDATA english string to act as default if
i don't find a language-specific one externally....

-mda


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From paul.spencer at boynings.demon.co.uk  Mon Nov  9 18:08:11 1998
From: paul.spencer at boynings.demon.co.uk (Paul Spencer)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and IE5 beta PR2
In-Reply-To: <E0zbxfc-0006U0-00@bowmore.cc.ic.ac.uk>
Message-ID: <000001be0c0b$e89672a0$020110ac@office>

>From: Jon.Bosak@eng.Sun.COM (Jon Bosak)
>Date: Thu, 5 Nov 1998 20:13:06 -0800
>
>It's my impression that Microsoft sees XSL simply as a way to do tag
>transformation and that their strategy for XML display is to use XSL
>to transform XML tags to HTML tags.  This means, of course, that you
>will not be able to use Microsoft tools that support XSL to do any
>formatting more complex than what can be expressed using HTML+CSS.

I agree that the current IE5 implementation of XSL only does tag
transformation. However, unless I have misunderstood CSS, I don't think
your conclusion follows.

I have used IE5 XSL to do reasonably complex formatting of XML
documents, including taking elements out of order, and displaying images
(URL in the XML) with hyperlinks to documents (also with their URL in
the XML). With a bit of judicious pre-processing of the XML using the
DOM, I also display another image a number of times according to a
number in the XML document.

I don't think I could do any of this with CSS. My understanding is that
CSS only lets you apply styles to what is there, in the order it is in
the XML document, XSL lets you move elements around and style them, but
you need the DOM to manipulate the PCDATA. This gives three layers of
functionality, each increasing in complexity of implementation. Correct?

Mind you, I don't think MS is correctly implementing the August 18
draft, but that is another matter, and I could be wrong.

Paul Spencer
Boynings Consulting
Tel: +44 (0)1628 687010 Fax: +44 (0)1628 687011
http://www.boynings.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From deke at tallent.com  Mon Nov  9 18:45:43 1998
From: deke at tallent.com (Deke Smith)
Date: Mon Jun  7 17:06:21 2004
Subject: XML and Internationalization...
Message-ID: <1301506998-42478233@tallent.com>

david@megginson.com, david@megginson.com said on 11/9/98 8:54 AM:

>One important point to note is that by itself, the 'xml:lang'
>attribute simply indicates the language of the content and attribute
>values -- it does not suggest that sibling elements with different
>xml:lang values either are or are not equivalents in other languages.
>For example, I could have
>
><itinerary>
>  <city xml:lang="fr">Montr&#233;al</city>
>  <city xml:lang="en">London</city>
>  <city xml:lang="it">Roma</city>
></itinerary>
>


Tony Graham, tgraham@mulberrytech.com said on 11/9/98 10:09 AM:

>While you may find concepts from the TMX work that are useful to you,
>TMX stands for Translation Memory eXchange, and is concerned with
>importing and exporting portions of translation memory -- phrases that
>have been translated once and saved so they don't need to be
>translated again -- between translation tools.  TMX has structures for
>parallel portions of text in multiple languages, but there is no
>concept that these chunks of text can, should, or will string together
>to make a coherent "document", in anybody's sense of the word.  The
>only markup in a TMX document, which is in XML, is concerned with
>delimiting and identifying the parallel chunks of text for the
>purposes of the translation tool: other markup from the source
>document may be saved in the TMX document (with significant XML
>characters escaped with entities) but only as a translation aid for
>those tools that can use it.

I have created phrase "substitution" scripts in Frontier and XML and ran into the same problem. I wanted to be able to "translate" phrases or words for use in multi-lingual Websites. It translates in the roughest sense: "Hello World!"=="?Hola Mundo!"=="?Bonjour Monde!".

I created my own translation DTD (I don't know of simple ones that may exist) -- and I think it shows, as David pointed out, that XML only provides a framework and the processing program has to provide an additional amount of structure not found in the DTD.

Under my dirty little DTD (built by necessity), the "Hello World!" example would be:

<PHRASE ID="Hello World!" xml:lang="en">
     <TRANSLATION xml:lang="fr">
          ?Bonjour Monde!
     </TRANSLATION>
     <TRANSLATION xml:lang="es">
          ?Hola Mundo!
     </TRANSLATION>
     <TRANSLATION xml:lang="de">
          Hallo Welt!
     </TRANSLATION>
</PHRASE>

This is a private DTD, so in my little world I know that the ID attribute of the PHRASE element equals the text nodes of the TRANSLATION elements. It would be asking too much of XML to enforce this structure.

TMX does provide this sort of function and structure, doesn't it? 

Here is how I would translate the previous example in TMX:

<?xml version="1.0?">
<!DOCTYPE tmx SYSTEM "http://www.lisa.org/tmx/tmx11.dtd">
<tmx version="1.1">
	<header
		creationtool="UserLand Frontier"
		creationtoolversion="5.1.4"
		datatype="PlainText"
		segtype="phrase"
		adminlang="en-us"
		srclang="EN"
		o-tmf="Frontier"
		o-encoding="MACINTOSH">
	</header>
	<body>
		<tu>
			<tuv lang="EN" creationid="BUZU">
				<seg>Hello world!</seg>
				</tuv>
			<tuv lang="FR" creationid="BUZU">
				<seg>?Bonjour Monde!</seg>
				</tuv>
			<tuv lang="ES" creationid="BUZU">
				<seg>?Hola Mundo!</seg>
				</tuv>
			<tuv lang="DE" creationid="BUZU">
				<seg>Hallo Welt!</seg>
				</tuv>
			</tu>
		</body>
</tmx>

Here's my question: 

As I understand it, TMX is a format for translation "dictionaries" -- or lists of equivalent words, phrases, sentences or paragraphs in different languages. TMX also allows the preservation of formating within phrases, such as boldface, italic, etc.

I always judge tools by what *I* need from them and that is what I need from TMX. Is it meant to do more than what I have asked it to do? Is this "dictionary" concept something TMX is *meant* for?

I am under the impression that TMX can also have embedded "macros" within phrases. By "macro", I mean processing commands that may be understood only by a specific scripting language. Am I right?

Deke

-----------------------------------------------------------------
Deke Smith
Tallent Communications Group, Brentwood TN
deke@tallent.com, 615-661-9878
-----------------------------------------------------------------
" The best way to predict the future is to invent it. " 
       - Alan Kay 



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Mon Nov  9 18:47:15 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:22 2004
Subject: Scheme (was: Walking the DOM)
References: <3.0.32.19981103102617.00afddb0@pop.intergate.bc.ca> <363F55AB.AEA4EB19@locke.ccil.org> <ncjsofsbvj3.fsf@nytrdc058.eq.gs.com>
Message-ID: <364738C3.5652BA70@locke.ccil.org>

Russ McManus wrote:

> My understanding is that R5RS includes 'do' in the language, which
> is a primitive, iterative construct.

"do" is iterative but not primitive: it is defined in R5RS
using a high-level macro (now the only kind of macro), using
tail iteration.

The *primitive* constructs are application, "if", "set!",
"lambda", and variable reference.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Mon Nov  9 18:48:10 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:22 2004
Subject: IE50 - XML Examples
Message-ID: <0015722D.3096@datacard.com>

     Hi Chris and all:
     
     Following steps have been done at my NT4.0 workstation:
     
     0. Install IE5.0 Beta
     
     1. Install SP3 for Visual C++ 5.0

     2. Install lastest MicroSoft Platform SDK (Sept. 98)

     3. Download from  
     http://www.microsoft.com/gallery/samples/download/first.htm

     STILL, I cannot link the example. Errors as follows:

     G:\mssdk\lib\kernel32.lib fatal error LNK1106: invalid file or disk full: 
cannot seek to 0x35cd5580

     G:\mssdk\lib\ole32.lib : fatal error LNK1106: invalid file or disk full: 
cannot seek to 0x35cb1cf1
Error executing link.exe.
     

     Can you see something that I missed or I need to to something else to
get the samples running? Or I have to use NT5.0 beta ?

     Please helps,

     SeanN

   


______________________________ Reply Separator _________________________________
Subject: RE: IE50 - XML Examples
Author:  Chris Lovett <clovett@microsoft.com> at Internet
Date:    11/7/98 8:34 PM


You need the IE5 SDK which you can download from: 
http://www.microsoft.com/gallery/samples/download/first.htm
     
-----Original Message-----
From: Sung_Nguyen@datacard.com [mailto:Sung_Nguyen@datacard.com] 
Sent: Friday, November 06, 1998 6:10 PM
To: Tyler Baker; Fernando Cabral
Cc: Tim Bray; len bullard; xml-dev@ic.ac.uk; Barclay Rockwood 
Subject: IE50 - XML Examples
     
     
     Hi all:
     
     I have trouble with linking the following example (downloaded from 
     MicroSoft site)
     This is the link error I got:
     
     "G:\mssdk\lib\ole32.lib : fatal error LNK1106: invalid file or disk 
     full: cannot seek to 0x35cb1cf1"
     
     The two files: "mshtml.h" msxml.h" I got from Internet SDK with IE4.0 
     I don't know if they are still compatible with IE5.0 and where I can 
     get new "mshtml.h" msxml.h" for IE5.0.
     
     Please point me the direction,
     
     Thanks a lot,
     
     SeanN
     
     --------------------------------------
     
     ////////////////////////////////////////////////////////////////////// 
     //////
     // Sample1.cxx: XML Object Model Sample 1 
     //-------------------------------------------------------------------- 
     ------
     // Copyright (c) 1998  Microsoft Corporation.  All Rights Reserved. 
     //
     // THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF 
     // ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO 
     // THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A 
     // PARTICULAR PURPOSE.
     //-------------------------------------------------------------------- 
     ------
     ////////////////////////////////////////////////////////////////////// 
     //////
     
     #include <windows.h>
     #include <windowsx.h>
     #include <stdlib.h>
     #include <stdio.h>
     #include <io.h>
     #include <hlink.h>
     #include <dispex.h>
     #include "mshtml.h"
     #include "msxml.h"
     #include <winnls.h>
     
     #define CHECKHR(x) hr = x; if (FAILED(hr)) goto Cleanup;
     #define SAFERELEASE(p) if (p) {(p)->Release(); p = NULL;} else ;
     
     ////////////////////////////////////////////////////////////////////// 
     //////
     // Synopsis: Create an IXMLElement of type t 
     ////////////////////////////////////////////////////////////////////// 
     //////
     IXMLElement* CreateXMLElement(IXMLDocument* pDoc, XMLELEM_TYPE t) 
     {
         IXMLElement* e;
         VARIANT type;
         type.vt = VT_I4;
         V_I4(&type) = t;
         VARIANT name;
     
         name.vt = VT_BSTR;
         V_BSTR(&name) = ::SysAllocString(L"ElementNode"); 
         HRESULT hr = pDoc->createElement(type, name, &e); 
         ::SysFreeString(V_BSTR(&name));
     
         return e;
     }
     
     ////////////////////////////////////////////////////////////////////// 
     //////
     // Synopsis: Create an XML Document from Scratch in memory 
     ////////////////////////////////////////////////////////////////////// 
     //////
     HRESULT MemDocument()
     {
         IXMLDocument           *pDoc = NULL; 
         IStream                *pStm = NULL; 
         IPersistStreamInit     *pPSI = NULL;
         IXMLElement            *enode = NULL, *el = NULL; 
         IXMLElement            *root = NULL; 
         LARGE_INTEGER li = {0, 0};
         HRESULT hr = S_OK;
         int i, j;
     
         // Create an empty XML document
         CHECKHR(CoCreateInstance(CLSID_XMLDocument, NULL, 
     CLSCTX_INPROC_SERVER,
                                     IID_IXMLDocument, (void**)&pDoc));
     
         // Query the IPersistStreamInit interface 
         CHECKHR(pDoc->QueryInterface(IID_IPersistStreamInit, (void 
     **)&pPSI));
     
         // Create an IStream
         CHECKHR(CreateStreamOnHGlobal(NULL, TRUE, &pStm)); 
         pStm->AddRef();
     
         //
         // Create an xml document with a root element 
         //
         ULONG ulWritten;
         CHECKHR(pStm->Write("<root/>", strlen("<root/>"), &ulWritten));
     
         // load the xml document
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL)); 
         CHECKHR(pPSI->Load(pStm));
     
         // get root element
         CHECKHR(pDoc->get_root(&root));
     
         //
         // Create an xml document in memory
         //
         for (i = 10; i > 0; i--)
         {
             enode = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT); 
             CHECKHR(root->addChild(enode, -1, -1));
     
             for (j = 10; j > 0; j--)
             {
                 el = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT); 
                 CHECKHR(enode->addChild(el, -1, -1)); 
                 SAFERELEASE(el);
             }
             SAFERELEASE(enode);
         }
     
     
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL)); 
         CHECKHR(pPSI->Save(pStm, TRUE));
     
         //
         // Load the document from the in-memory stream 
         //
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL)); 
         CHECKHR(pPSI->Load(pStm));
     
     Cleanup:
     
         SAFERELEASE(root);
         SAFERELEASE(el);
         SAFERELEASE(enode);
         SAFERELEASE(pPSI);
         SAFERELEASE(pStm);
         SAFERELEASE(pDoc);
     
         return hr;
     }
     
     int _cdecl 
     main(int argc, char *argv[])
     {
         HRESULT hr = S_OK;
     
         CoInitialize(NULL);
     
         hr = MemDocument();
     
         CoUninitialize();
     
     
         return hr == 0 ? 0 : 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; 
(un)subscribe xml-dev
To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Mon Nov  9 19:08:52 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:22 2004
Subject: XML and IE5 beta PR2
References: <000001be0c0b$e89672a0$020110ac@office>
Message-ID: <36473C9A.2E09D648@eng.sun.com>

Paul Spencer wrote:
> 
> Mind you, I don't think MS is correctly implementing the August 18
> [XSL] draft, but that is another matter, and I could be wrong.

With "xsl:eval", "xsl:script" and many other proprietary extensions,
yet without even "xsl:process-children", I think you're clearly right.
W3C's XSL pattern syntax is there, but not a lot else.

This would have been a good time to use the namespace mechanism, for
example "msxsl:" for those extensions, and "xsl:" for W3C features.

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


From Sung_Nguyen at datacard.com  Mon Nov  9 20:03:33 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:22 2004
Subject: Commercial XML Parser in C++ 
Message-ID: <001573DA.3096@datacard.com>

     
     
     Hi:
     
     Anyone use a commercial XML Parser in C++ ??? 
     I need one.
     
     Thanks alot,
     
     SeanN

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From smangat at Adobe.COM  Tue Nov 10 01:48:28 1998
From: smangat at Adobe.COM (Satwinder Mangat)
Date: Mon Jun  7 17:06:22 2004
Subject: WebDAV
In-Reply-To: <0015722D.3096@datacard.com>
Message-ID: <000f01be0c4b$62c87f20$8f9e2099@dsds3.corp.adobe.com>

Hi,

What is the website for WebDAV?

Thanks
Satwinder Mangat

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jtauber at jtauber.com  Tue Nov 10 02:06:12 1998
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:06:22 2004
Subject: WebDAV
Message-ID: <002001be0c4e$2c0833b0$4a850786@ecn08.curtin.edu.au>

-----Original Message-----
From: Satwinder Mangat <smangat@Adobe.COM>
>What is the website for WebDAV?


http://www.ics.uci.edu/~ejw/authoring/

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 10 04:42:33 1998
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:06:22 2004
Subject: Last Call issued on initial stylesheet linking draft
In-Reply-To: <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog.com>

With respect to http://www.w3.org/TR/1998/WD-xml-stylesheet-19981001 ...


This mail has (1) a general plea, followed by some numbered
suggestions/corrections to the draft.

<Plea>
It seems to me that the mechanism for linking between an
XML document and a style sheet is exactly the same as linking
between an XML document and its DTD or Schema, and exactly
the same as linking to a namespace, or to a related image,
or almost any other link.

I think the processing instruction is unfortunate: XLink should
be used.  If XLink is not powerful enough to do this, fix it.
If XLink is too complex to do something this simple, fix it.

If XLink should be replaced by or (as I suspect) merged with RDF,
fine, use RDF.  Style and behaviour/Action sheets are in many
ways very similar to the schema definitions one might expect to
find at the other end of a Namespace URI, too.

Tim (or the group for whom Tim posted) clearly realised the
inadequacy of the processing instruction synrax, as the message
was mostly an apology for using it.

Please reconsider.
</plea>

<Suggestions>

If you go ahead with the draft as it stands,

[1] please can you add an example of right-to-left text in a
    style sheet title, and show how to indicate the language?
    That isn't clear to me.

[2] there is an implication in the productionPseudoAttValue[3]
    that general entity references to the five predefined internal
    general entities are to be expanded inside the text of
    processing instructions.  This is not part of XML 1.0 behaviour
    (see Section 2.6 in XML 1.0, where the content of a processing
    instruction is simply
    [16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>') 
    with no allowance for entity references to be understood (although
    they are not forbidden).

    The "Associating Stylesheets with XML documents" draft needs to
    say whether this new treatment of processing instructions is
    2a) not the case -- &lt; is simply the 4 characters &, l, t, ; inside
	a processing instructihons, as now;

    2b) undefined, as with the present draft (i think through oversight)

    2c) optional depending on the processor

    2d) required in <?xml-stylesheet...> PIs but forbidden, optional or
	undefined elsewhere

    2e) required retroactively in all conforming XML software in all PIs

    2f) some other interpretation

    I'm listing the obvious interpretations to show why it needs to be
    clarified.

[3] please can we avoid the normative reference to html 4.0 in the
    first paragraph of section 1?  It might make it harder for a future
    version of html to be based on xml, as you'd end up with a circular
    dependency :)  I don't think this is a big deal, though, and I
    don't think the other references to html 4 matter as much, if at all.
    I'd prefer to see a note that pointed out the similarity, and then
    a duplication of the appropriate text, I think.

[4] in production [2], the space should be S? I assume, as should the
    trailing one in production [1] -- none of the examples match the
    grammar as it stands.

[5] can the style sheet have an associated language?  Does that make sense??

[6] Finally, give an example of a Link: header to make the mapping clear.

</Suggestions>

I hope these comments help.


Lee

-- 
Liam Quin, GroveWare Inc., Toronto;  The barefoot programmer
l i a m q u i n     at    i n t e r l o g    dot   c o m
irc.technonet.net::ankle5    irc.dal.net::ankle{MD}


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Tue Nov 10 07:53:06 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:22 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML Application
Message-ID: <01BE0C86.DBD2AA40@grappa.ito.tu-darmstadt.de>

Robert C. Lyons wrote:

> List item #3 should be changed to the following (the changes are in bold):
> 
> 3. An XML processor must pass the single character &#xA; in place
> of &#xD; or &#xD;&#xA; appearing in its input. (2.11)

Section 2.11 states, "To simplify tasks of applications, wherever an external parsed entity or the literal entity value of an internal parsed entity contains either the literal two-character sequence "#xD#xA" or a standalone literal #xD, an XML processor must pass to the application the single character #xA. (This behavior can conveniently be produced by normalizing all line breaks to #xA on input, before parsing.)"

These two sentences seem to contradict each other.  The first talks about internal and external parsed entities.  The second talks about all line breaks, which seems to imply the document entity as well.  As far as I can tell, the document entity is a parsed entity (this is never actually stated, but strongly implied and the only reasonable conclusion), but is neither internal nor external.

I assume that the second sentence is the correct one, as this is the only reasonable behavior from the application's point of view.  My point in bringing this up is not to throw a wrench into the works, but just to add this to the list of minor errata.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 10 09:32:29 1998
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:06:22 2004
Subject: Commercial XML Parser in C++
In-Reply-To: Sung_Nguyen@datacard.com's message of "Mon, 9 Nov 1998 13:57:46 -0600"
References: <001573DA.3096@datacard.com>
Message-ID: <f5bogqfki5i.fsf@cogsci.ed.ac.uk>

See
 http://www.ltg.ed.ac.uk/software/xml/
for a description and licence terms for our C (not C++ as such) XML
parser, API and toolkit.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 10 14:48:23 1998
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:06:22 2004
Subject: Endtag attributes
Message-ID: <36474321.DE4EA5A3@toolsmiths.se>

Hi,

As a part of a small R&D project Im I trying to look into the issues
of elements vs. attributes and having attributes in endtags
(im know its outside current xml standard).

But Im having trouble finding any work being presented around
pros and cons with endtag attributes.

Is there anyone that could point me to research /papers/discussion on
the net ?
This would help me enormously.

Im especially interested in arguments for having endtag arguments.

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


From majayg at iitk.ac.in  Tue Nov 10 15:53:46 1998
From: majayg at iitk.ac.in (Ajay Gangwar)
Date: Mon Jun  7 17:06:22 2004
Subject: Converting HTML to well formed XML
Message-ID: <002e01be0cc1$b93bad70$52a21090@cse.iitk.ernet.in>

Self:
>I need to convert HTML document to well formed XML 
>document. Can someone please guide me how to go
>about doing this? Are any utilities available for this?

Simon:
>Unfortunately, no one yet (so far as I know) has created 
>a friendly one-step legacy HTML->well-formed XML 
>syntax HTML converter.  That's a nice opportunity there for 
>some publicity, if not necessarily $$$...

>Of course, if you want to to use non-HTML vocabulary, 
>you're talking  about something  much larger  than 
>syntax, [...snip...]

 Actually what I was expecting when I posted that question, 
was some pointers  from the 'gurus' on how to go about 
implementing such a convertor ( i.e  a discussion on the 
issues involved)

Help ;-(

- Ajay Gangwar
  majayg@iitk.ac.in



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From larsga at ifi.uio.no  Tue Nov 10 15:59:05 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:22 2004
Subject: Endtag attributes
In-Reply-To: <36474321.DE4EA5A3@toolsmiths.se>
References: <36474321.DE4EA5A3@toolsmiths.se>
Message-ID: <wk67cna6cp.fsf@ifi.uio.no>


* Anders W. Tell
| 
| As a part of a small R&D project Im I trying to look into the issues
| of elements vs. attributes and having attributes in endtags
| (im know its outside current xml standard).
| 
| Is there anyone that could point me to research /papers/discussion on
| the net ?

I doubt that there is anything, but if there is you can find it at

<URL:http://www.oasis-open.org/cover/>


Some cons I thought of:

 - additional complexity in APIs and syntaxes, or, if these are kept
   as they are, in parsers
 - endtag attributes are not available until the entire element has
   been parsed (and it may be _very_ large), so that if the values
   influence the treatment of the element contents in any way, this
   may cause performance problems
 
The only pro I can think of is pretty far-fetched:

 - might be easier to generate markup from some kinds of applications,
   since attribute values would not have to be determined until after
   the element contents had been written out

--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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 10 16:24:55 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:22 2004
Subject: Converting HTML to well formed XML
Message-ID: <3.0.32.19981110082051.00b3a5d0@pop.intergate.bc.ca>

At 09:19 PM 11/10/98 +0530, Ajay Gangwar wrote:
>Self:
>>I need to convert HTML document to well formed XML 
>>document. Can someone please guide me how to go
>>about doing this? Are any utilities available for this?

There are a variety of HTML parsers in perl available on CPAN.
Once you've parsed some HTML, emitting a WF XML version ought
to be trivial. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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_DeRose at Brown.edu  Tue Nov 10 16:30:45 1998
From: Steven_DeRose at Brown.edu (Steve DeRose)
Date: Mon Jun  7 17:06:22 2004
Subject: Endtag attributes
In-Reply-To: <36474321.DE4EA5A3@toolsmiths.se>
Message-ID: <v03110702b26e0732ec6c@[153.34.245.150]>

At 3:31 PM -0400 11/9/98, Anders W. Tell wrote:
>
>As a part of a small R&D project Im I trying to look into the issues
>of elements vs. attributes and having attributes in endtags
>(im know its outside current xml standard).
>
>But Im having trouble finding any work being presented around
>pros and cons with endtag attributes.
>
>Is there anyone that could point me to research /papers/discussion on
>the net ?
>This would help me enormously.
>
>Im especially interested in arguments for having endtag arguments.

There is a detailed discussion of the semantics and design of attributes
vs. elements in my book "The SGML FAQ Book", that you may find helpful
(along with discussions of nearly every other controversial question about
SGML and XML).

Common practice is that attributes represent information relevant to an
element as a whole -- not to a tag. And in XML, tags aren't commonly
considered first-class objects: they're a syntactic way of labelling the
actual objects, namely elements; so giving them their own properties seems
to me a bit out of keeping with the model. Given that, it would not fit to
have different attributes on the end-tag than on the start-tag. On the
other hand, having the same attributes on both ends would be redundant.

One argument I have heard for them was that if you had them you might be
able to parse backwards. But I have never found a good occasion to do that,
and if in fact you can parse XML backwards otherwise, it hardly matters
whether the parser finds the attributes first or last anyway. If you allow
them, you have additional semantics to define (the syntax is obviously
trivial), like what it means if you have the same name (with the same or
different values) on both ends of an element, etc. etc.

I don't know of an analogous precedent in other languages either (though
perhaps there's one out there somewhere). Thus, I think you'll find little
discussion in the literature.

I've seen them show up in HTML as typos. Perhaps you could describe
specifically what it is you think they would be useful for.....

Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd
Visiting Chief Scientist, Scholarly Technology Group, and
   Adjunct Associate Professor, Brown University;
Chief Scientist, Inso Corporation



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Tue Nov 10 16:59:25 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:22 2004
Subject: Endtag attributes
In-Reply-To: <36474321.DE4EA5A3@toolsmiths.se>
Message-ID: <000201be0ccb$abd35200$73e987cb@NT.JELLIFFE.COM.AU>

> From:   Anders W. Tell

> Im especially interested in arguments for having endtag arguments.

One good reason pro is because when you are doing text processing using a
streaming tool (i.e. one that does not load the document in memory)
sometimes you wish to write out attributes with values collected from
processing sub elements.

Consider an application which reads a table and adds an attribute with the
column and row count.

This is a kind of foward-reference problem. In streaming text processing
tools you:

* have two passes, or
* write out the values of all the attributes in an external entity file (so
that the XML parser resolves the references on next document load), or
* have a built-in reference resolving phase such as OmniMakr uses.

Until recently (and for all I know, maybe still) most text processing of
non-HTML SGML/XML marked-up files was done using streaming tools (i.e. with
event programming).

The trouble with having end-tag attributes for this kind of use is that even
though it would be easier to generate such documents, an end-tag attribute
solution does not buy you anything, because if you are using streaming tools
you will still need the "collected value" attributes when you come to the
start-tag, in order to set up processing of the rest of the element. You
still need some step to move the end-tag attribute to the start-tag.

And, as has been mentioned, maybe people who are used to tag-based text
processing rather than element (i.e. range) based processing will not be
encouraged to alter their thinking, if end-tag attributes were allowed.

Perhaps the one thing that end-tag attributes might be useful for is
checksums, though.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 10 17:04:51 1998
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:06:22 2004
Subject: Endtag attributes
References: <v03110702b26e0732ec6c@[153.34.245.150]>
Message-ID: <364762DE.1AC6B1C7@toolsmiths.se>

Steve DeRose wrote:

> At 3:31 PM -0400 11/9/98, Anders W. Tell wrote:
> >
>
> I've seen them show up in HTML as typos. Perhaps you could describe
> specifically what it is you think they would be useful for.....

The UseCase that interests me is the class of attributes which cannot be created
without accessing all children, such as summation/aggregates.

This may be important when accessing xml data through Stream interfaces such as
SAX.
It may prove inefficient to process a large section of the stream before actually
writing the
attribute to the next stream in a chain of streams.

So adding an attributes at the end allows the developers to keep a pure stream
programming model without sacrificing performance.

One of the most interesting attributes is "Signature" which cannot be calculated
(write) before
the sub fragment has been processed. It s also impossible to validate (read) a
Signature
before the endtag arrives.

/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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 10 17:16:13 1998
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:06:23 2004
Subject: Endtag attributes
References: <000201be0ccb$abd35200$73e987cb@NT.JELLIFFE.COM.AU>
Message-ID: <364765C0.37BEC7F3@toolsmiths.se>

Rick Jelliffe wrote:

> > From:   Anders W. Tell
>
> > Im especially interested in arguments for having endtag arguments.
>
> One good reason pro is because when you are doing text processing using a
> streaming tool (i.e. one that does not load the document in memory)
> sometimes you wish to write out attributes with values collected from
> processing sub elements.
>
> Consider an application which reads a table and adds an attribute with the
> column and row count.
>
> This is a kind of foward-reference problem. In streaming text processing
> tools you:
>
> * have two passes, or
> * write out the values of all the attributes in an external entity file (so
> that the XML parser resolves the references on next document load), or
> * have a built-in reference resolving phase such as OmniMakr uses.
>
> Until recently (and for all I know, maybe still) most text processing of
> non-HTML SGML/XML marked-up files was done using streaming tools (i.e. with
> event programming).

Is possible to save parts of the document im memory before writing it to the
next stream in a chain. This may not be desirable in cases when documents are
large .


> The trouble with having end-tag attributes for this kind of use is that even
> though it would be easier to generate such documents, an end-tag attribute
> solution does not buy you anything, because if you are using streaming tools
> you will still need the "collected value" attributes when you come to the
> start-tag, in order to set up processing of the rest of the element. You
> still need some step to move the end-tag attribute to the start-tag.

Not all attributes , which are calculated after processing a fragment, are usable

before the all other attributes and children have been processed. An example
of this type of attributes is "Signature" which can may be read when the
start-tag
token arrives but the validation of the signature cannot be perfomed until the
endtag arrives.

However I agree with you that most attributes dont add anything when added in the
end-tag.

> And, as has been mentioned, maybe people who are used to tag-based text
> processing rather than element (i.e. range) based processing will not be
> encouraged to alter their thinking, if end-tag attributes were allowed.

True,

>
> Perhaps the one thing that end-tag attributes might be useful for is
> checksums, though.

And its alter ego Signatures :)


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


From nwoh at software-ag.de  Tue Nov 10 17:42:47 1998
From: nwoh at software-ag.de (Nigel Hutchison)
Date: Mon Jun  7 17:06:23 2004
Subject: XML and Internationalization...
In-Reply-To: <1301506998-42478233@tallent.com>
Message-ID: <3.0.6.32.19981110184224.00938920@pophost.software-ag.de>

 I think one of the issues in the internationalisation of SGML/XML/HTML is
as follows.

Internationalising a document means creating it so that subsequently is
very convenient to be localised.

That implies if I give my SGML product documentation to a professional
translators to be translated into German say, how do they  know which parts
to be translated and which to be left alone?

for example if one of them finds

<select name="transport">
<option value="car">Car</option>
<option value="bus">Bus<//option>
</select>
<input type="submit" name="Submit" value="Submit">
<address street ="Transport Street, 234</address>


How does he or she know to translate "Car" and "Bus" but not "transport".,
"car" ,"bus" or "Transport Street"?
Which "submit" does he or she translate?

We need some kind of annotation. This annotation could or should be have
SGML syntax so that high powered SGML authoring tools can present the text
to be translated, and protect the text which must be left alone.

In an XML scenario one possible option is that you leave the XML data as it
is and provide localised style sheets to present the data  according to the
locale. Using xsl:define-constant to define localisable strings 

like this.
 
<!-- Please Localise values (but not names!!)-->
  <xsl:define-constant name="Car" value="Car"/> 
  <xsl:define-constant name="Bus" value="Bus"/>
  <xsl:define-constant name="Transport" value="Transport"/>
 <xsl:define-constant name="Submit" value="Submit"/> <!-- in the sense of
sending a form off"-->
<!-- End Localise -->

Then the translator at least knows what he has to do.



Nigel W. O. Hutchison
Technical Consultant
Software AG Germany		                              
mailto:nwoh@software-ag.de
           
Tel +49 (0)6151 92 1207                   
                                                                   *


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Tue Nov 10 18:51:15 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:23 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog.
 com>
References: <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>

As moderator I try to keep neutral on the direction that the W3C takes, so
please excuse a smallish bit of frustration about the non-development and
non-use of XLink. If you think I'm out of line, I'll shut up.

At 23:42 09/11/98 -0500, Liam R. E. Quin wrote:
>
>I think the processing instruction is unfortunate: XLink should
>be used.  If XLink is not powerful enough to do this, fix it.
>If XLink is too complex to do something this simple, fix it.

I share this sentiment in general. I think XLink is one of the most
exciting things about the family of X*L. I think we are suffering too much
complexity, and foozle **simply because XLink STILL isn't ready**.

I have designed my DTDs (CML and VHG) with the idea that there will be a
linking mechanism similar to the current XLink. XLink (as XML-Link) was
first announced about 18 months ago as far as I remember and it was
certainly reasonable to expect that it would be in common use by now. The
fact that it is not and we have no indication of timescales has - I suspect
- disillusioned many people. I still keep the faith, but it's hard,
especially when there are virtually no engines even in prototype that we
can play with.

In passing I think that a serious drawback of the W3C's approach is that
there is no incentive for anyone to experiment in public view. *if* we had
been experimenting with XLink, namespaces and the rest then we would have a
lot more useful experience to go on by now. In fact I think innovation and
exploration in XML is suffering in comparison with the development of HTML. 

"Plan to throw the first one away - you will anyway" (Fred Brooks). I wish
there was more encouragement for the enthusiasts to develop the first one.

I acknowledge that this somewhat frustrating plea may spring from the fact
of my no longer having access to the W3C deliberations and - in retrospect
- I expend my sympathy to the brave souls on this list who have always been
in this position. It can look very bleak from the outside. The *perceived*
messages [i.e. the electronic body language] are:
	- it's not worth non-W3C members trying to get involved. [If we had taken
this view we wouldn't have SAX and we wouldn't have XSchema].
	- it's not worth minnows (like the Xschema group, me, etc.) trying to do
anything because MS/NS/XYZPQR/W3C are going to do it anyway. [Same comment
- the movement on XML-type, XML-data, etc. has been almost retrograde.] 
	- XML is only for companies and individuals shouldn't really be involved. 


>
>If XLink should be replaced by or (as I suspect) merged with RDF,
>fine, use RDF.  

This appals me. Is it true? likely? Because if so, Xlink will be (a)
delayed another year or so (b) end up as so complicated that it will be
unusable. I continue to hold that RDF is too complicated for most people
and will reduce rather than encourage the use of metadata a linking. [Look
how apparently simple namespaces are and how slow the development appears
to be other than to identify the vendor of the software - hardly a semantic
revolution.]

Having slightly flamed off, I would like the replies to be constructive -
not "what is wrong", but "can this be got moving again in practice"?. One
thing at least is that XML-DEV can move reasonably quickly.

	P.



Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Tue Nov 10 18:51:17 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:23 2004
Subject: XSchema
Message-ID: <3.0.1.16.19981110195101.09ef254a@pop3.demon.co.uk>

I have spent the last week or so hacking XSchema into JUMBO and testing it
out. 

Firstly to say many thanks to those who have contributed and especially to
Ron Bourret, Simon StL and John Cowan [I hope I haven't missed anyone] for
driving this through. 

It is exactly what is wanted at present. The mapping onto the DTD is
precise and essential for me. Without it I suspect that it would be more
difficult to implement correctly.

I have fitted it to JUMBO with the functions:
	- offering a list of potential child elements for a given element. [This
doesn't yet do on-the-fly content validation and I doubt it will. It gives
a JComboBox of the possible children. If someone has a Model validation
routine I can fit it.] This allows XSchema-drive editing of element names
and structure.
	- offering a table of attributes with the various options (Required,
Value, etc.) driving the editability of various fields. 

	By implication, of course, the editor can be used to edit XSchemas.

I have used RonB's DTD2XSchema translator - works fine, but I think Ron
said it needed slight tweaks. 

** Is there a way of capturing the external DTD subset in SAX, or AElfred,
or any other parser? It really only needs to capture the URL? Do I have to
subclass an Entity handler? In this way it would be possible to read in the
DTD automatically, transform to XSchema and display.] **

** Is there any way to extract the complete "DTD" - i.e. external and
internal subsets (but without parameter/general entities) from
SAX/AElfred/XYZPQR? **

I hope to release the XSchema-aware JUMBO (i.e. a structure/attribute-aware
XML editor) very shortly so people can verify if I have got the mechanics
right and whether this is something useful. 

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Tue Nov 10 19:14:20 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:23 2004
Subject: Software for markup? (was Re: XML Search Engine)
In-Reply-To: <13889.62092.676344.644070@localhost.localdomain>
References: <3.0.32.19981105094725.009209b0@pop.intergate.bc.ca>
 <3.0.32.19981105094725.009209b0@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981110201402.1bef8c00@pop3.demon.co.uk>

I have what (I hope) is an easier problem and would be grateful for
pointers to existing software that can be used to mark up XML documents
[primarily in English].

We have developed an XML representation (VHG) for controlled vocabularies
which are widely used for "encoding" reports and other information. These
vocabularies have about 10K terms each, consisting of single words or
phrases (e.g. "acne", "Asian cholera", etc.. [Our current examples are
dictionaries of disease terms from world authorities.] The [pharmaceutical]
industry/regulators spend much time in "encoding" (== markup).

In general the dictionaries do not have indexHeadings, stemming,
pronunciations, US/Eur variants etc. (though we are hoping to promote the
communal capture of such knowledge through WWW-based collaboration). We
wish to be able to markup such terms as automatically as possible, e.g. 
<P>The patient developed acne</P>
 could be transformed to
<P>The patient developed <simpleLink href="icd10_L70.0">acne</simpleLink></P>

The current encoding procedures are not complex (often manual) and I'm not
looking for rocket science (e.g. no automatic extraction of terms, concept
analysis, etc.) I want to avoid re-inventing the wheel because I assume
lots have people have already done this.

	TIA

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Tue Nov 10 19:16:45 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:23 2004
Subject: XLink - where are we? [tiny amount of frustration]
Message-ID: <3.0.32.19981110111212.00b43950@pop.intergate.bc.ca>

At 06:58 PM 11/10/98, Peter Murray-Rust wrote:
>I share this sentiment in general. I think XLink is one of the most
>exciting things about the family of X*L. I think we are suffering too much
>complexity, and foozle **simply because XLink STILL isn't ready**.

The good news is that there has been, since August, an XML Linking
WG.  The bad news is that so far it hasn't done much (the old story,
resource constraints and people being real busy).  I share Peter's
opinion that XLink will be the next high-impact thing thing to come
out of the XML process, and that this should happen sooner rather 
than later. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ralph at fsc.fujitsu.com  Tue Nov 10 20:11:53 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:23 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
References: <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>

At 06:58 PM 11/10/98, Peter Murray-Rust wrote:
>I have designed my DTDs (CML and VHG) with the idea that there will be a
>linking mechanism similar to the current XLink. XLink (as XML-Link) was
>first announced about 18 months ago as far as I remember and it was
>certainly reasonable to expect that it would be in common use by now. The
>fact that it is not and we have no indication of timescales has - I suspect
>- disillusioned many people. I still keep the faith, but it's hard,
>especially when there are virtually no engines even in prototype that we
>can play with.

Apparently, my announcement of HyBrick 0.8 on this list - and several
others - has been completely overlooked by yourself and the other people
holding this discussion. HyBrick 0.8 is a working implementation of
XLink/XPointer available *now*. You can download the English-language menu
version from our site at FSC: http://collie.fujitsu.com/HyBrick/.
Japanese-language readers should go to
http://www.fujitsu.co.jp/hypertext/free/HyBrick/download2.html

Best regards,

Ralph E. Ferris
Fujitsu Software Corporation

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From travis at betty.cnidr.org  Tue Nov 10 21:55:46 1998
From: travis at betty.cnidr.org (K. Travis Walsh)
Date: Mon Jun  7 17:06:23 2004
Subject: Oracle XML
Message-ID: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>


Oracle officially anounced today it's XML strategy.

For those of you who didn't know there is a java parser built into this
new release of Oracle 8i.

They also made thier XML web site live:

www.oracle.com/xml

So you can see what they have now, and what they are going to have in the
future.

The initiative to have XML support came from inside developers looking for
solutions to internal problems, so it's an honest effort.  Not just a me
too patch.

Wonderful things are happening!

   **********************
  * K. Travis Walsh      *
 *  MCNC / CNIDR          * 
 *  Programmer / Analyst  * 
  * travis@mcnc.org      * 
   **********************
 My Quote of the day:

I took a speed-reading course and read War and Peace in twenty minutes. It involves Russia.  -Woody Allen


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Tue Nov 10 22:57:21 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:23 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
References: <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981110235158.1b479670@pop3.demon.co.uk>

At 03:07 11/11/98 -0500, Ralph Ferris wrote:
>
>Apparently, my announcement of HyBrick 0.8 on this list - and several
>others - has been completely overlooked by yourself and the other people
>holding this discussion. HyBrick 0.8 is a working implementation of

No - I was aware of the work that you and others have been doing. And many
thanks for it. I was also aware that there is a reconstituted (==
revitalised??) XLink-WG. 

What sparked me off was the implication - real or not - that XLink might
undergo yet another redraft/latency period. And also - unless I'm out of
touch - the absence of documents to work with. 

We have a vicious circle here which we have to try and break:
	- no authoring tools ==> no documents
	- no documents ==> no XML-aware tools
	- no XML-aware tools ==> no real *interoperable* applications
	- no applications ==> no drive for authoring tools

My concern is that there are a small number of us - including yourselves -
that are tackling small parts of the problem. We need ways of bringing this
together. SAX, Xschema, various companies, and others including myself have
offered code as OpenSource - this helps. But we don't have critical mass.

**In particular we are not exploring interoperability**. By this I mean
that person A sends a document to person B in a different organisation and
B tries to work with the document. Not easy. But that's what our real aim
is, surely? [Documents can, of course include data and other things like
molecules, music, vector graphics, etc.] Until we do that we aren't
exploring and innovating in XML. We are simply looking at ways of passing
pseudo-paper over the wire. As I have bemoaned before, virtually no-one is
yet passing XML over the wire.

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Tue Nov 10 23:54:28 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:23 2004
Subject: Endtag attributes
In-Reply-To: <364762DE.1AC6B1C7@toolsmiths.se>
References: <v03110702b26e0732ec6c@[153.34.245.150]>
	<364762DE.1AC6B1C7@toolsmiths.se>
Message-ID: <13896.53527.214735.361579@localhost.localdomain>

Anders W. Tell writes:

 > So adding an attributes at the end allows the developers to keep a
 > pure stream programming model without sacrificing performance.

Yes, but what you save in the writing, you lose in the reading: a SAX
client reading your XML element would have to buffer the whole
contents until it got to the end tag to make certain that there were
no important attributes there.

A specific version of a specific XML document is written only once,
but it can be read many times; when you are forced to choose between
adding complexity to writing or reading, writing should end up drawing
the shorter straw.


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


From ralph at fsc.fujitsu.com  Wed Nov 11 01:04:52 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:23 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.1.16.19981110235158.1b479670@pop3.demon.co.uk>
References: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111080054.00a0cae0@pophost.fsc.fujitsu.com>

At 11:51 PM 11/10/98, Peter Murray-Rust wrote:
>
>What sparked me off was the implication - real or not - that XLink might
>undergo yet another redraft/latency period.

All the more reason to mention HyBrick. We're not starting from square one.
We have a working implementation that should be seen as a baseline. I have,
in fact, just sent the "reconstituted" WG a very pointed message about
*not* ignoring Fujitsu and Hybrick. I have also volunteered to be an editor
for the XPointer spec., in which capacity I - as Fujitsu's representative -
will oppose any attempts to take this subject off into the wild blue yonder. 

> And also - unless I'm out of
>touch - the absence of documents to work with.

I have been thinking of posting a message with a "request for content."
These would be documents that I would include with the HyBrick
distribution. Of course, these doucments have to have
publically-distributable DTDs and DSSSL stylesheets. 

Unfortunately, though, the "traditional" DSSSL folks seem bent on ignoring
HyBrick as well. Current users write messages to the DSSSL list asking for
advice on how to output RTF from Jade, while the developers have abandoned
DSSSL altogether for the siren-song of XSL.

>
>We have a vicious circle here which we have to try and break:
>	- no authoring tools ==> no documents

In my view, the abandonment of DSSSL by the very experts who created it is
at least partially responsible for this. Last year at at SGML/XML '97, we
demonstrated early work on a GUI style sheet editor for DSSSL. We showed it
to some of the WKLs (Well-Known Luminaries), who said "looks cool" - and
went off to do XSL.

The problem is, what "ecological niche" does XSL occupy? For the basics -
and a lot more - you can go the XML transform to HTML/CSS route. DSSSL
supports power users. In fact, it supports basic users maybe as well as any
other method. It just that users were told they need to know Scheme to use
DSSSL, which isn't true. What is needed for style sheets is a good GUI
tool. Instead, the WKLs preferred the more intellectually interesting job
of defining yet another syntax. Given this context, we haven't presued work
on the DSSSL editor.

> As I have bemoaned before, virtually no-one is
> yet passing XML over the wire.

To keep this message relatively short, I'll just say that HyBrick does
support retrieval of XML documents over the Web; some folks have been able
to retrieve the sample document by Eliot Kimber that's on our Web site. SP,
which HyBrick runs on, doesn't support the use of proxy servers, however,
so the document is inaccessible to many others. We're looking into this,
with an eye to supporting proxy servers in the next release. That doesn't
address the general issue that your raising of course.  Hopefully, though,
it will be a start.


Best regards,

Ralph E. Ferris 
Fujitsu Software Corporation 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Wed Nov 11 01:15:18 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:23 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
References: <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>

At 03:07 11/11/98 -0500, Ralph Ferris wrote:
>
>Apparently, my announcement of HyBrick 0.8 on this list - and several
>others - has been completely overlooked by yourself and the other people
>holding this discussion. HyBrick 0.8 is a working implementation of
>XLink/XPointer available *now*. You can download the English-language menu
>version from our site at FSC: http://collie.fujitsu.com/HyBrick/.

It is - as far as I know - the most advanced XLink implementation. 
I have some problems with Hybrick and I'd be grateful from clarification on
certain points. These aren't meant to detract from what has been done.

(a) it appears to be primarily an SGML tool rather than an XML one. The
DTDs shipped with the distribution all have minimisation controls (or
whatever the "- o" is called). When I try to run any of my XML files it
throws errors on the files.

(b) the XML files appear to reference these SGML (non-XML) DTDs so although
it may be valid SGML it doesn't seem to be valid XML. I suspect it may need
a catalog since one is shipped with it.

(c) it appears to require all applications to have a stylesheet - i.e.
there is no default display and it's therefore primarily for rendering XML
as text with hyperlinks.

(d) the license restricts use to evaluation only which means it is not
really usable for experimentation - especially without an API, etc. For
example, I cannot demonstrate it to students.

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From donpark at quake.net  Wed Nov 11 02:43:26 1998
From: donpark at quake.net (Don Park)
Date: Mon Jun  7 17:06:23 2004
Subject: Converting HTML to well formed XML
Message-ID: <000c01be0d1c$df7f7470$2ee044c6@arcot-main>

>Unfortunately, no one yet (so far as I know) has created
>a friendly one-step legacy HTML->well-formed XML
>syntax HTML converter.  That's a nice opportunity there for
>some publicity, if not necessarily $$$...


Docuverse HTML SDK can be used to build such a converter easily.  What it
contains is a SAX parser interface to Swing's HTML parser which means you
can use your XML tools on HTML documents.

However, Swing's HTML parser has mishandles unknown tags so it is not a
perfect solution.

You can find HTML SDK at http://www.docuverse.com/htmlsdk

Best,

Don Park
Docuverse



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jswleung at hkbu.edu.hk  Wed Nov 11 03:11:43 1998
From: jswleung at hkbu.edu.hk (Josef Siu-wai Leung)
Date: Mon Jun  7 17:06:23 2004
Subject: Embedding figures
Message-ID: <Pine.A41.3.96.981111105102.34856A-100000@net1.hkbu.edu.hk>

Hi,

I would like to learn about how to show images into any bottom level
elements of XML in IE5 Beta.  I think I need to add an element "Figure*"
(which indicates a filename) into every original bottom level element. 
Would you please share with me a working XML/XSL example.

Cheers,
Josef



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ralph at fsc.fujitsu.com  Wed Nov 11 03:14:33 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:24 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
References: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111100820.00a00630@pophost.fsc.fujitsu.com>

At 02:14 AM 11/11/98, Peter Murray-Rust wrote:

>(a) it [HyBrick] appears to be primarily an SGML tool rather than an XML >
one. The
>DTDs shipped with the distribution all have minimisation controls (or
>whatever the "- o" is called). When I try to run any of my XML files it
>throws errors on the files.

HyBrick runs on SP and Jade, which support "full" SGML. To work within the
syntax defined by the XML spec., the SGML declaration for XML has to be
called. At the moment, this has to be done explicitly. If you look in the
XML-sample directory, you'll see that the catalog file contains the entry:
 
SGMLDECL "..\dtd\xml.dcl"
 
In a future release, this will be done "automatically" when the XML
processing instruction is encountered.

>
>(b) the XML files appear to reference these SGML (non-XML) DTDs so although
>it may be valid SGML it doesn't seem to be valid XML. I suspect it may need
>a catalog since one is shipped with it.

See previous comment.

>
>(c) it appears to require all applications to have a stylesheet - i.e.
>there is no default display and it's therefore primarily for rendering XML
>as text with hyperlinks.

Yes - a DSSSL style sheet must be provided.

>
>(d) the license restricts use to evaluation only which means it is not
>really usable for experimentation - especially without an API, etc. For
>example, I cannot demonstrate it to students.

I'm not sure what you mean here. You're right that it's a binary
distribution, which does not expose an API for developers. I would think
though that what you would be trying to demonstrate to students would be
functionality, and you can certainly do that.


Best regards,

Ralph E. Ferris
Fujitsu Software Corporation

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cbullard at hiwaay.net  Wed Nov 11 03:24:10 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:24 2004
Subject: XLink - where are we? [tiny amount of frustration]
References: <3.0.32.19981110111212.00b43950@pop.intergate.bc.ca>
Message-ID: <364902AE.34A3@hiwaay.net>

Tim Bray wrote:
> 
> The good news is that there has been, since August, an XML Linking
> WG.  The bad news is that so far it hasn't done much (the old story,
> resource constraints and people being real busy).  I share Peter's
> opinion that XLink will be the next high-impact thing thing to come
> out of the XML process, and that this should happen sooner rather
> than later. -Tim

Me too.

When advocating XML in other communities such as VRML, XLink is 
cited as one of the advantages of XML.  Not being part of the 
deliberations, I am uncertain as to what the delays are given 
that the original drafts were promising and on the surface, 
quite clear.  For the work I am doing, an XLink model would 
be useful if for nothing else, the properties, just as the 
RDF Dublin Core has been and XSchema may be.  One benefit 
of suddenly being forced to do everything relationally is 
the insight into some of the designs floating about.  So, please: 

1.  A standard for primitive/core datatypes
2.  XLinks

ASAP,

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


From tyler at infinet.com  Wed Nov 11 03:46:25 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:24 2004
Subject: Oracle XML
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
Message-ID: <3649088C.3EADA703@infinet.com>

"K. Travis Walsh" wrote:

> Oracle officially anounced today it's XML strategy.
>
> For those of you who didn't know there is a java parser built into this
> new release of Oracle 8i.
>
> They also made thier XML web site live:
>
> www.oracle.com/xml
>
> So you can see what they have now, and what they are going to have in the
> future.
>
> The initiative to have XML support came from inside developers looking for
> solutions to internal problems, so it's an honest effort.  Not just a me
> too patch.
>
> Wonderful things are happening!

It is nice to see that they are supporting SAX as well.  I think the question now with XML tools in regard to
SAX is "who does not support SAX"?

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


From cathy at bd748.pku.edu.cn  Wed Nov 11 03:52:26 1998
From: cathy at bd748.pku.edu.cn (Chang Ming)
Date: Mon Jun  7 17:06:24 2004
Subject: Web pages in non-Roman scripts
Message-ID: <002201be0d26$d58da220$1c7669a2@cathy.bd748.pku.edu.cn>

Hi,

With this mail, i attach a small chinese xml file and its css file, all in
utf-8.

When i display this xml in IE5 Beta 2, it does not recognize the css. The
document is displayed in plain text style, and all start tags is left
displaying with content. I have tried coding CSS in GB-2312, still it gives
no effect.I will try other encoding later. I want to know what kind of
encoding should CSS use? Is there a need to add an encoding attribute in the
style sheet PI?

Another question: if i want use Chinese in markup, is UNICODE the only
choice?

Thank you,

 Chang Ming

Computer Sci. and Tech. Institute of Peking University



begin 666 doc.xml
M/#]X;6P@=F5R<VEO;CTB,2XP(B!E;F-O9&EN9STB551&+3@B(#\^#0H\(41/
M0U194$4@YI:'YJ&C("!;#0H\(45,14U%3E0@YI:'YJ&C("CFH(?IHI@LY:V0
MYJ"'Z:*8+.:7I>:<GRSFKK4K*3X-"CPA14Q%345.5"#FH(?IHI@@*"-00T1!
M5$$I/@T*/"%%3$5-14Y4(.6MD.:@A^FBF" H(U!#1$%402D^#0H\(45,14U%
M3E0@YI>EYIR?("@C4$-$051!*3X-"CPA14Q%345.5"#FKK4@*"-00T1!5$%\
MY86SZ92NY:V7*2H^#0H\(45,14U%3E0@Y86SZ92NY:V7("@C4$-$051!*3X-
M"ET^#0H\/WAM;#IS='EL97-H965T('1Y<&4](G1E>'0O8W-S(B!H<F5F/2)D
M;V,N8W-S(B _/@T*/.:6A^:AHSX-"CSFH(?IHI@^YJ"'Z:*8/"_FH(?IHI@^
M#0H\Y:V0YJ"'Z:*8/N6MD.:@A^FBF#POY:V0YJ"'Z:*8/@T*/.:7I>:<GSYX
M>'AXY;FT>'CFG(AX>.:7I3POYI>EYIR?/@T*/.:NM3[GK*SDN(#FKK4\Y86S
MZ92NY:V7/N6%L^F4KN6MESPOY86SZ92NY:V7/N>LK.2X@.:NM>>LK.2X@.:N
MM>>LK.2X@.:NM>>LK.2X@.:NM>>LK.2X@.:NM>>LK.2X@.:NM>>LK.2X@.:N
MM>>LK.2X@.:NM>>LK.2X@.:NM>>LK.2X@.:NM>>LK.2X@.:NM>>LK.2X@.:N
MM2X\+^:NM3X-"CSFKK4^YZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRL
MY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRL
MY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRL
MY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRLY+J,YJZUYZRL
7Y+J,YJZU/"_FKK4^#0H\+^:6A^:AHSX`
`
end

begin 666 doc.css
M#0KFH(?IHI@@>R!C;VQO<B Z(')E9#L-"@D)"69O;G0M<VEZ92 Z(#$V<'0[
M#0H)"0EF;VYT+69A;6EL>2 Z(.F:MN2YICL-"@D)"71E>'0M86QI9VX@.B!C
M96YT97([( T*"0D)9F]N="UW96EG:'0@.B!B;VQD.PT*"0D)9&ES<&QA>3H@
M8FQO8VL[?0T*#0KEK9#FH(?IHI@@>R!F;VYT+7-I>F4@.B Q-'!T.PT*"0ET
M97AT+6%L:6=N(#H@<FEG:'0[#0H)"61I<W!L87DZ(&)L;V-K.R!]#0H-"N:N
MM2![( T*"0EF;VYT+7-I>F4@.B Q,G!T.PT*"0EF;VYT+7=E:6=H=" Z(&QI
M9VAT97([#0H)"71E>'0M:6YD96YT(#H@,C1P=#L-"@D)9&ES<&QA>3H@8FQO
M8VL@?0T*#0KFEZ7FG)\@>PT*"0EF;VYT+69A;6EL>3H@Z;N1Y+V3.PT*"0EF
M;VYT+7-I>F4Z(#$P<'0[#0H)"6-O;&]R.B!B;'5E.R -"@D)9&ES<&QA>3H@
M8FQO8VM]"0T*#0KEA;/IE*[EK9<@>PT*"0EF;VYT+69A;6EL>3H@YJ6WY+V3
M7T=",C,Q,CL-"@D)9F]N="UW96EG:'0Z(&)O;&0[#0H)"69O;G0M<VEZ93H@
M,31P=#L-"@D)=F5R=&EC86PM86QI9VXZ(&)A<V4[#0H)"61I<W!L87DZ(&EN
+;&EN97T)"0T*#0H`
`
end


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Wed Nov 11 04:31:50 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:24 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
References: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981110221631.008ec900@amati.techno.com>

At 02:14 AM 11/11/98, Peter Murray-Rust wrote:

>(c) it appears to require all applications to have a stylesheet - i.e.
>there is no default display and it's therefore primarily for rendering XML
>as text with hyperlinks.

Not trying to be difficult, but how could any useful form of default
presentation other than running everything together or making every element
a separate block be provided by a DTD-inspecific tool?  I don't know of any
generalized SGML tool that provides any useful sort of default styling. The
best is Arbortext's Document Architect, which provides a sort of wizard by
which it asks a bunch of questions and makes some informed guesses and then
generates a style sheet that can be a reasonable starting place (it can
also be more trouble than it's worth depending on what sort of DTD you
happen to have).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Suli.Ding at geis.ge.com  Wed Nov 11 04:40:46 1998
From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS))
Date: Mon Jun  7 17:06:24 2004
Subject: converting document to XML
Message-ID: <F2A665AC0054D1119D0F00805FFECA1201915302@roc01bxgeisge>

The UNIX version of the "doc2xml" are available from 
	http://www.geocities.com/SiliconValley/Platform/4871/

A new command line option "-e" has been added to not produce empty element.
For example,
	<CurDtl></CurDtl>
will not be produced to the output file.

Another command line option "-o" can be specified for the output file name.
For example
	doc2xml -tedi.tbl -e -oXML.out isa.edi
will produce the XML document in file "XML.out".

Regards,

Suli Ding

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From suhas at india.tek.com  Wed Nov 11 08:43:50 1998
From: suhas at india.tek.com (Suhas Joshi)
Date: Mon Jun  7 17:06:24 2004
Subject: embedding "behviour" in XML document
Message-ID: <36494BD2.79666333@kiwi.india.tek.com>

Hi ,

    Could anyone tell how a complete object (including *behaviour*) be
sent /recieved using XML . Any pointers will help (I am a newbie to xml)

Thanks & Regards,
Suhas.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From anderst at toolsmiths.se  Wed Nov 11 08:55:01 1998
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:06:24 2004
Subject: Endtag attributes
References: <v03110702b26e0732ec6c@[153.34.245.150]>
		<364762DE.1AC6B1C7@toolsmiths.se> <13896.53527.214735.361579@localhost.localdomain>
Message-ID: <364841D2.617349EF@toolsmiths.se>

david@megginson.com wrote:

> Anders W. Tell writes:
>
>  > So adding an attributes at the end allows the developers to keep a
>  > pure stream programming model without sacrificing performance.
>
> Yes, but what you save in the writing, you lose in the reading: a SAX
> client reading your XML element would have to buffer the whole
> contents until it got to the end tag to make certain that there were
> no important attributes there.

Yes and No, Since end-tag attributes is an extension to current xml the above
problem may
be offset by adding an end-tag marker to attributes in the DTD, DCD, XSchema's.
Which means the applications know that the specific attribute may/must occur in
the end-tag.

>
> A specific version of a specific XML document is written only once,
> but it can be read many times; when you are forced to choose between
> adding complexity to writing or reading, writing should end up drawing
> the shorter straw.

Depends on the UseCase in question, certainly on the internet there is probably a
80-20 (read-write)
balance for *static* documents but more and more application/servers generates
documents or fragments
on demand with no possibility to cache. An example of this are dynamic queries.

Another UseCase is InterProcessCommunication such as WebRPC. Here *documents* are
generated
on the fly and discarded on reception and caching many documents/requests/replies
may not be a viable solution.

As far as complexity goes, the only change is to  add StartTag APIs to EndTag's.

Im not proposing to add end-tag attributes, just trying to understand the
implications if the feature was available..

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


From rbourret at ito.tu-darmstadt.de  Wed Nov 11 12:42:21 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:24 2004
Subject: XSchema
Message-ID: <01BE0D78.74BCA7F0@grappa.ito.tu-darmstadt.de>

Peter Murray-Rust wrote:

> I have fitted it to JUMBO with the functions:
> 	- offering a list of potential child elements for a given element. [This
> doesn't yet do on-the-fly content validation and I doubt it will. It gives
> a JComboBox of the possible children. If someone has a Model validation
> routine I can fit it.] This allows XSchema-drive editing of element names
> and structure.

If I ever find time to write a validation module, on-the-fly validation should be a freebie.  I figure the validator will be a SAX parser filter initialized with an XSchema document.  The application (e.g. Jumbo) hooks this to a real parser, registers an ErrorHandler, and passes the Stream of XML to be validated; the return value from parse(), along with any values sent to the ErrorHandler, tell the application whether validation succeeded or not.

> I have used RonB's DTD2XSchema translator - works fine, but I think Ron
> said it needed slight tweaks. 

Still needs updating to the latest spec.  Works starts this weekend.

> ** Is there a way of capturing the external DTD subset in SAX, or AElfred,
> or any other parser? It really only needs to capture the URL? Do I have to
> subclass an Entity handler? In this way it would be possible to read in the
> DTD automatically, transform to XSchema and display.] **
>
> ** Is there any way to extract the complete "DTD" - i.e. external and
> internal subsets (but without parameter/general entities) from
> SAX/AElfred/XYZPQR? **

I misread this at first.  What Peter wants is either (a) the system ID of the external subset, or (b) the stream of bytes in the complete DTD.  I assume the reason is so he can automatically feed it to my DTD-to-XSchema converter; currently, he would have to prompt the user for this information.

Another alternative is to fix my converter so it can read the DTD directly from the XML file and discards the rest (it currently reads only external subsets).  Is there any advantage to working only with external subsets?

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 11 16:22:28 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:25 2004
Subject: Open-source XLink library (was Re: XLink - where are we?)
In-Reply-To: <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
References: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <199811111622.LAA12163@hesketh.com>

After spending the last few months talking and talking about how amazingly
cool XLink _could_ be, I've taken a few steps toward _doing_ things with
XLink.  The steps aren't lovely or stupendous (yet), but I hope that they
might represent a step forward.  The code is not yet ready for prime time,
but the discussion on this list makes it fairly clear that there is a need
for this kind of project.

Working from the 3/3/98 Working Draft, I've put together a few small Java
examples that use XLink and am at work on a library based on John Cowan's
ParserFilter class that extracts the linking information from a document,
allowing the application to process the document without having to deal
with the issues involved in creating and managing links.  Right now the
library supports simple and extended links, but not hub groups or attribute
remapping.  I'm planning on adding legacy support for HTML's A element at
some point in the future as well.

The examples are from Building XML Applications, and were small, simple,
one-off applets.  They can be found at the bottom of
http://www.simonstl.com/buildxml/.  They use image maps (my handling of
text link proved disastrous) and are unfortunately a bit slow as a result.
They pretty much just show what some _very_ simple XLink applications might
look like.  The source code for these examples will be in the book, and (if
I can get the necessary permissions from my editor) may appear online as well.

The library is and will be open source, though at this point I haven't
firmly decided on a license. (GPL is likely, in some slightly modified
form.) I should emphasize that the library is in (fairly ugly) alpha form;
the feature set is not yet nearly complete, especially the LinkSet class.
The basic XLinkFilter has worked on the samples on which I've tested it,
transforming multi-directional links into more workable sets of single
direction links.  The LinkSet is an extended Vector, but will probably
change to something more flexible when Java 1.2 comes along.  (I will try
to keep a 1.1 version, however.)  Information on the XLinkFilter and
supporting code is at http://www.simonstl.com/projects/xlinkfilter/.

This filter only handles XLink; XPointer is a necessary complement, but
another large piece to deal with.  Support for a DOM model in addition to
SAX is another necessary piece, but one that I haven't yet begun.

Documentation at present is weak, and the comments in the code aren't
enough.  They will improve, and I will add real JavaDoc comments as well.
(Promise!)

All contributions/modifications/suggestions on functionality, code,
licensing, etc. are welcome.  I'll be in and out for the next few days, but
will be returning to more focused work on this library over the weekend.



Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 11 17:01:43 1998
From: Curt.Arnold at hyprotech.com (Arnold, Curt)
Date: Mon Jun  7 17:06:25 2004
Subject: Schema support in IE5
Message-ID: <61DAD58E8F4ED211AC8400A0C9B468730120FA@THOR>

I've just browsed through the Schema support preview stuff on IE5 and was
wondering whether it or the DCD note best represents Microsoft's thinking on
Schema tags.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Wed Nov 11 17:18:11 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:25 2004
Subject: Schema support in IE5
Message-ID: <3.0.32.19981111091752.00b4fdf0@pop.intergate.bc.ca>

At 10:01 AM 11/11/98 -0700, Arnold, Curt wrote:
>I've just browsed through the Schema support preview stuff on IE5 and was
>wondering whether it or the DCD note best represents Microsoft's thinking on
>Schema tags.

Care to give us a report on what it looks like to someone without
preconceptions? -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simpson at polaris.net  Wed Nov 11 19:43:31 1998
From: simpson at polaris.net (John E. Simpson)
Date: Mon Jun  7 17:06:25 2004
Subject: ID attribute defaults
In-Reply-To: <3.0.32.19981111091752.00b4fdf0@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111144155.010ea4d0@nexus.polaris.net>

I understand why IDs don't typically have defaults, each one required to be
unique.

OTOH, what about a data-based (not database-based) XML app whose content
model, especially at the top of the tree, consists largely of elements
which may occur only once in an entire document instance? It seems to me
that there's still potential value in assigning such elements a fixed
"default" value -- primarily for purposes of internal cross-references.

Tim Bray's annotated XML spec says (in the annotaton on production [56]
regarding the IDREF validity constraint), "In general, it's a good idea to
attach ID attributes to as many elements as possible in every document,
because, later, if you decide you need to point at anything, you'll be
happy if it has an ID attribute ready for use." Agreed. 

Later, in the discussion of the #FIXED attribute type (prod. [60]), he says: 

    ....suppose, for example, that I insert a pointer here to 
    my favorite piece of the XML spec. When I do this, I use an 
    element named Sref (for Spec-ref), which becomes an A 
    element in the HTML version. However, in all cases, I want 
    that pointer to get another attribute target='spec'", so 
    that when you use it, it takes effect in the left-hand frame, 
    which is named spec.

    So that I don't have to enter that attribute in each Sref 
    element, the internal subset contains this:

       <!ATTLIST Sref target CDATA #FIXED "spec">

This is exactly what I'd like to do. But this seems like something of a
gimmick to reproduce the effect of the ID/IDREF attribute types, one which
furthermore requires an app to interpret -- not leveraging the built-in
cross-reference facility.

What am I missing? Is there some way both to use ID/IDREF *and* not require
the document author to supply IDs on her own?

Thanks for any brainstorms,
John E. Simpson

========================================================
John E. Simpson            | It's no disgrace t'be poor,
simpson@polaris.net        | but it might as well be.
http://www.flixml.org      |            -- "Kin" Hubbard

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From joel at spooky.emcs.cornell.edu  Wed Nov 11 19:57:33 1998
From: joel at spooky.emcs.cornell.edu (Joel Bender)
Date: Mon Jun  7 17:06:25 2004
Subject: XML for Network Topology
Message-ID: <v04011701b26f94eb473b@[128.253.245.66]>

I'm interested in (1) a DTD for networking, specifically to describe a
topology of networks, routers, ports, etc.  If one doesn't already exist,
contact me and we'll form a splinter group to create one (my guess would be
to start with SNMP data and go from there).

I am also interested in (2) a DTD for building systems...fans, pumps,
valves, boilers, chillers, cooling towers, meters (electric, gas, water,
sewer).  My mission is to build a suite of applications that can be used
for diagnostics (if I shut of pump #3, who will no longer get water?
Building #6 lost power, which circuit is that?), analysis, modeling, etc.
With "smart buildings" there is an increasing interconnection between
components (air-conditioning, fire control, security).

Before trying to work on (2) it would be informative to work on (1).  I
think XML would be an excellent mechanism to transfer this structured data
between tools.


Joel
------------------------------------------------------------------
Joel Bender                         Voice:        607-255-8880
Senior Programmer/Analyst           FAX:          607-255-5377
Utilities Department                131 Humphreys Service Building
Cornell University                  Ithaca, NY  14853-3701
------------------------------------------------------------------

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From xmldoubts at hotmail.com  Wed Nov 11 20:14:17 1998
From: xmldoubts at hotmail.com (XML Doubts)
Date: Mon Jun  7 17:06:25 2004
Subject: Sun XML Lib
Message-ID: <19981111201248.7097.qmail@hotmail.com>

Hi,

Has any one used the Sun XML library. My question is how to access the 
child nodes from the root. 
I have tried

....main(String args[]){
....
XmlDocument doc;
Element root = doc.getDocumentElement();
System.out.println("\nRoot: "+root.getTagName());
System.out.println("\nFirstChild:"+
                    (root.getFirstChild()).getNodeName());
...
}
The first print statement prints the root element, but the second print 
statement prints #text which is not what I want. I want to print the 
node name.

Like for example in the XML file
<?xml version="1.0"?>
<poem>
<line>Roses are red,</line>
</poem>

The first print statement prints "poem"
The second print statement prints #text.
I want "line" to be printed.

And also how do I get the text inside the "line" tag.
This might be trivial question but I am just a beginner. So bear with 
me.

Can anyone help.

Thanks.

Bye

______________________________________________________
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 11 20:16:52 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:25 2004
Subject: ID attribute defaults
Message-ID: <3.0.32.19981111120856.00ba33e0@pop.intergate.bc.ca>

At 02:41 PM 11/11/98 -0500, John E. Simpson wrote:
>I understand why IDs don't typically have defaults, each one required to be
>unique.
>
>OTOH, what about a data-based (not database-based) XML app whose content
>model, especially at the top of the tree, consists largely of elements
>which may occur only once in an entire document instance? 

Yes, that's a plausible scenario in which a defaulted ID attribute 
might be useful.  Sorry... XML rules it out.

As for my having defaulted the "target" attribute in the annotated
spec, the "target" is the *same* on every annotation, that's why
it's defaulted.  Nothing could be more different from an ID attribute.
The annotation doesn't say (maybe should) that the thing that 
generates the HTML copies through any attributes it doesn't
recognize, so the defaulted target="spec" ends up in every one
of the hundreds of annotations. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From xmldoubts at hotmail.com  Wed Nov 11 20:17:04 1998
From: xmldoubts at hotmail.com (XML Doubts)
Date: Mon Jun  7 17:06:25 2004
Subject: Sun XML Lib
Message-ID: <19981111201321.2085.qmail@hotmail.com>

Hi,

Has any one used the Sun XML library. My question is how to access the 
child nodes from the root. 
I have tried

....main(String args[]){
....
XmlDocument doc;
Element root = doc.getDocumentElement();
System.out.println("\nRoot: "+root.getTagName());
System.out.println("\nFirstChild:"+
                    (root.getFirstChild()).getNodeName());
...
}
The first print statement prints the root element, but the second print 
statement prints #text which is not what I want. I want to print the 
node name.

Like for example in the XML file
<?xml version="1.0"?>
<poem>
<line>Roses are red,</line>
</poem>

The first print statement prints "poem"
The second print statement prints #text.
I want "line" to be printed.

And also how do I get the text inside the "line" tag.
This might be trivial question but I am just a beginner. So bear with 
me.

Can anyone help.

Thanks.

Bye

______________________________________________________
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Wed Nov 11 20:34:52 1998
From: harvey at eccnet.eccnet.com (Betty Harvey)
Date: Mon Jun  7 17:06:25 2004
Subject: XML for Network Topology
In-Reply-To: <v04011701b26f94eb473b@[128.253.245.66]>
Message-ID: <Pine.LNX.3.96.981111152257.5581B-100000@eccnet.eccnet.com>


Hi Joel:

	The company I4I has a DTD they used as a demonstration of the S4 
product to show networking.  I am not sure how complete the 
DTD is or whether they would be willing to publicly provide
the DTD.

	Your second question about DTDs for diagnostic systems has
been created by DoD for Interactive Electronic Technical Manuals
(MIL-PRF-87269).  There are two different associated DTD's, one is
a generic layer which controls hyperlinking.  The other is a content
layer which deals with the system/subsystem, etc.  These DTDs are
full-blown SGML DTDs and are rather complex.

	MIL-PRF-87269 is currently undergoing revision and is out
for comments.  One of the items on the revision is supporting XML
data.  The draft specification can be downloaded from
ftp://eccnet.eccnet.com/pub/ietm/87269b.zip if interested.
Also http://www.ietm.net contains information about and links
to IETMs.

	Good luck.

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.eccnet.com               | Washington,DC SGML Users Grp
URL:  http://www.eccnet.com            | http://www.eccnet.com/sgmlug/
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/  


On Wed, 11 Nov 1998, Joel Bender wrote:

> I'm interested in (1) a DTD for networking, specifically to describe a
> topology of networks, routers, ports, etc.  If one doesn't already exist,
> contact me and we'll form a splinter group to create one (my guess would be
> to start with SNMP data and go from there).
> 
> I am also interested in (2) a DTD for building systems...fans, pumps,
> valves, boilers, chillers, cooling towers, meters (electric, gas, water,
> sewer).  My mission is to build a suite of applications that can be used
> for diagnostics (if I shut of pump #3, who will no longer get water?
> Building #6 lost power, which circuit is that?), analysis, modeling, etc.
> With "smart buildings" there is an increasing interconnection between
> components (air-conditioning, fire control, security).
> 
> Before trying to work on (2) it would be informative to work on (1).  I
> think XML would be an excellent mechanism to transfer this structured data
> between tools.
> 
> 
> Joel
> ------------------------------------------------------------------
> Joel Bender                         Voice:        607-255-8880
> Senior Programmer/Analyst           FAX:          607-255-5377
> Utilities Department                131 Humphreys Service Building
> Cornell University                  Ithaca, NY  14853-3701
> ------------------------------------------------------------------
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simpson at polaris.net  Wed Nov 11 20:44:32 1998
From: simpson at polaris.net (John E. Simpson)
Date: Mon Jun  7 17:06:25 2004
Subject: ID attribute defaults
In-Reply-To: <3.0.32.19981111120856.00ba33e0@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111154340.010f3ec0@nexus.polaris.net>

Thanks for the reply, Tim.

>Yes, that's a plausible scenario in which a defaulted ID attribute 
>might be useful.  Sorry... XML rules it out.

As I understood (but hoped otherwise -- or at least hoped that there'd be
some trick to accomplish the same goal, without having to create
app-specific attributes like Sref to do it). 

>As for my having defaulted the "target" attribute in the annotated
>spec, the "target" is the *same* on every annotation, that's why
>it's defaulted.  Nothing could be more different from an ID attribute.

Yeah, but.... In an element tree in which many elements at the top layer
must be one-of-a-kind, the target would be the same for every
cross-reference, too. So why not default it (or so I thought) with a fixed
ID value?

I hesitate to call this an idee fixe. Probably should have hesitated a bit
longer.

Thanks again.
JES

========================================================
John E. Simpson            | It's no disgrace t'be poor,
simpson@polaris.net        | but it might as well be.
http://www.flixml.org      |            -- "Kin" Hubbard

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Wed Nov 11 21:19:05 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:25 2004
Subject: Get encoding
Message-ID: <00159D4E.3096@datacard.com>

     Hi:
     
     How do I get encoding type from an XML doc ?
     I am using Mircosoft C++ XML parser come with IE4.0;
     there is no such "get_encoding()" message in 
     XMLDoc interface.

     Thanks for your helps

     SeanN

     

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From DKACKMAN at agchem.com  Wed Nov 11 21:41:21 1998
From: DKACKMAN at agchem.com (Don Kackman)
Date: Mon Jun  7 17:06:25 2004
Subject: DTD inheritance?
Message-ID: <8424EFA3C1F7D1118B7300A0C9C57C192084FC@mpl_nt9.agchem.com>

Hello,

I've got two document types with associated DTDs. The first is a subset
of the second. I don't want to merge these two DTDs into one file but
also don't want to maintain both files seperately.

Is it possible to include one DTD in another through an external entity
reference? If so how?

Also if so, can I declare additional attributes in the second DTD for
elements originally declared in the first?

Thanks a lot,

Don Kackman
dkackman@agchem.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Wed Nov 11 21:52:08 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:26 2004
Subject: ID attribute defaults
Message-ID: <00159E10.3096@datacard.com>

     Hi Gurus:
     
     In the following XML file - 
     What should I do to get the attributes SRC, WIDTH, HEIGHT 
     and ALT of the element PREVIEW-SMALL?
     
     I would like to print out something like this:
     
     PREVIEW-SMALL ELEMENT has 3 ATTRIBUTES:
             SRC="images/burl-s.jpg" 
             WIDTH="300" 
             HEIGHT="194" 
             ALT="Vase and Stones"
     
     Thanks you for any helps
     
     SeanNg
     sung_nguyen@datacard.com
     
     
     --------------------------------------------------------------------
     
     <?xml version="1.0"?>
     <AUCTIONBLOCK>
        <ITEM>
           <TITLE>Vase and Stones</TITLE>
           <ARTIST>Linda Mann</ARTIST>
           <DIMENSIONS>20x30 inches</DIMENSIONS> 
           <MATERIALS>Oil</MATERIALS>
           <YEAR>1996</YEAR>
           <DESCRIPTION/>
           <PREVIEW-SMALL SRC="images/burl-s.jpg" WIDTH="300" HEIGHT="194" 
     ALT="Vase and Stones"><!--The small image--></PREVIEW-SMALL>
           <PREVIEW-LARGE SRC="images/burl.jpg" WIDTH="640" HEIGHT="413" 
     ALT="Vase and Stones"/>
           <BIDS>
              <BID>
                 <PRICE>3300</PRICE>
                 <TIME>9:19:32 AM</TIME>
                 <BIDDER>John</BIDDER>
                 <TIMESTAMP>1315</TIMESTAMP>
              </BID>
              <BID>
                 <PRICE>3200</PRICE>
                 <TIME>8:18:31 AM</TIME>
                 <BIDDER>Andrew</BIDDER>
                 <TIMESTAMP>1308</TIMESTAMP>
              </BID>
              <BID>
                 <PRICE>3100</PRICE>
                 <TIME>2:48:08 PM</TIME>
                 <BIDDER>Chris</BIDDER>
                 <TIMESTAMP>1307</TIMESTAMP>
              </BID>
              <BID>
                 <PRICE>3000</PRICE>
                 <TIME>2:47:58 PM</TIME>
                 <BIDDER>opening price</BIDDER>
                 <TIMESTAMP>1298</TIMESTAMP>
              </BID>
           </BIDS>
           <MTIME>
              <TIMESTAMP>1315</TIMESTAMP>
              This is an example of mixed content
           </MTIME>
        </ITEM>
     </AUCTIONBLOCK>
     

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Wed Nov 11 22:08:28 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:26 2004
Subject: parsing the attributes
Message-ID: <00159E6A.3096@datacard.com>

     <<<< Sorry about the previous post to the "ID attribute defaults" thread >>
     
     Hi Gurus:
     
     In the following XML file - 
     What should I do to parse all attributes of the element 
     PREVIEW-SMALL ?
     
     I would like to print out something like this:
     
     PREVIEW-SMALL ELEMENT has 3 ATTRIBUTES:
             SRC="images/burl-s.jpg" 
             WIDTH="300" 
             HEIGHT="194" 
             ALT="Vase and Stones"
     
     Thanks you for any helps 
     
     SeanNg
     sung_nguyen@datacard.com
     
     
     --------------------------------------------------------------------
     
     <?xml version="1.0"?>
     <AUCTIONBLOCK>
        <ITEM>
           <TITLE>Vase and Stones</TITLE>
           <ARTIST>Linda Mann</ARTIST>
           <DIMENSIONS>20x30 inches</DIMENSIONS> 
           <MATERIALS>Oil</MATERIALS>
           <YEAR>1996</YEAR>
           <DESCRIPTION/>
           <PREVIEW-SMALL SRC="images/burl-s.jpg" WIDTH="300" HEIGHT="194" 
     ALT="Vase and Stones"><!--The small image--></PREVIEW-SMALL>
           <PREVIEW-LARGE SRC="images/burl.jpg" WIDTH="640" HEIGHT="413" 
     ALT="Vase and Stones"/>
           <BIDS>
              <BID>
                 <PRICE>3300</PRICE>
                 <TIME>9:19:32 AM</TIME>
                 <BIDDER>John</BIDDER>
                 <TIMESTAMP>1315</TIMESTAMP>
              </BID>
              <BID>
                 <PRICE>3200</PRICE>
                 <TIME>8:18:31 AM</TIME>
                 <BIDDER>Andrew</BIDDER>
                 <TIMESTAMP>1308</TIMESTAMP>
              </BID>
              <BID>
                 <PRICE>3100</PRICE>
                 <TIME>2:48:08 PM</TIME>
                 <BIDDER>Chris</BIDDER>
                 <TIMESTAMP>1307</TIMESTAMP>
              </BID>
              <BID>
                 <PRICE>3000</PRICE>
                 <TIME>2:47:58 PM</TIME>
                 <BIDDER>opening price</BIDDER>
                 <TIMESTAMP>1298</TIMESTAMP>
              </BID>
           </BIDS>
           <MTIME>
              <TIMESTAMP>1315</TIMESTAMP>
              This is an example of mixed content
           </MTIME>
        </ITEM>
     </AUCTIONBLOCK>
     
     
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk 
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; 
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; 
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
     

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From larsga at ifi.uio.no  Wed Nov 11 22:53:54 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:26 2004
Subject: DTD inheritance?
In-Reply-To: <8424EFA3C1F7D1118B7300A0C9C57C192084FC@mpl_nt9.agchem.com>
References: <8424EFA3C1F7D1118B7300A0C9C57C192084FC@mpl_nt9.agchem.com>
Message-ID: <wk1zn9j10t.fsf@ifi.uio.no>


* Don Kackman
| 
| I've got two document types with associated DTDs. The first is a subset
| of the second. I don't want to merge these two DTDs into one file but
| also don't want to maintain both files seperately.
| 
| Is it possible to include one DTD in another through an external entity
| reference? If so how?

In file sub-dtd.dtd:

[...lots of declarations...]

<!ENTITY % base-dtd SYSTEM "base-dtd.dtd">
%base-dtd;

where the file base-dtd.dtd contains the declarations common to both
DTDs.

You will probably have some problems with content models when you try
this if sub-dtd.dtd contains element declarations. If so, it may be
helpful for you to know that section 4.2 of the spec says: "If the
same entity is declared more than once, the first declaration
encountered is binding; at user option, an XML processor may issue a
warning if entities are declared multiple times."
 
This can be used to make 'hooks' in content models where sub-DTDs can
insert the new elements they introduce.

| Also if so, can I declare additional attributes in the second DTD
| for elements originally declared in the first?

Yes, the XML spec explicitly provides for this. In section 3.3 it
says: "When more than one AttlistDecl is provided for a given element
type, the contents of all those provided are merged."

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


From peter at ursus.demon.co.uk  Wed Nov 11 23:06:30 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:26 2004
Subject: XSchema
In-Reply-To: <01BE0D78.74BCA7F0@grappa.ito.tu-darmstadt.de>
Message-ID: <3.0.1.16.19981111205003.366f6a2a@pop3.demon.co.uk>

At 13:37 11/11/98 +0100, Ronald Bourret wrote:
>
>If I ever find time to write a validation module, on-the-fly validation
should be 
It'll be real fun - good for your soul...

a freebie.  I figure the validator will be a SAX parser filter initialized
with an XSchema document.  The application (e.g. Jumbo) hooks this to a
real parser, registers an ErrorHandler, and passes the Stream of XML to be
validated; the return value from parse(), along with any values sent to the
ErrorHandler, tell the application whether validation succeeded or not.

sounds fine. I am personally not keen on validate-after-every-keystroke
approach and would expect that I would either work with a single element
("validate the children of this element" and/or "validate the children of
the parent of this element" ) or "validate the whole document". If the
former, then we simply pass the stream of XML from the node in question
(JUMBO can extract this at present).
>
>> I have used RonB's DTD2XSchema translator - works fine, but I think Ron
>> said it needed slight tweaks. 
>
>Still needs updating to the latest spec.  Works starts this weekend.

Great.
>
>> ** Is there a way of capturing the external DTD subset in SAX, or AElfred,
>> or any other parser? It really only needs to capture the URL? Do I have to
>> subclass an Entity handler? In this way it would be possible to read in the
>> DTD automatically, transform to XSchema and display.] **
>>
>> ** Is there any way to extract the complete "DTD" - i.e. external and
>> internal subsets (but without parameter/general entities) from
>> SAX/AElfred/XYZPQR? **
>
>I misread this at first.  

Probably my fault - was late at night.

What Peter wants is either (a) the system ID of the external subset, or (b)
the stream of bytes in the complete DTD.  I assume the reason is so he can
automatically feed it to my DTD-to-XSchema converter; currently, he would
have to prompt the user for this information.

Exactly right. At present I can read in a complete foo.xsc and (in some
mindless moment) bolt in Ron's tool so it can read foo.dtd. But these have
to be actuated manually ("Edit | Read XSchema") on menu. And it will be an
invalid approach if there is an internal subset.
>
>Another alternative is to fix my converter so it can read the DTD directly
from the XML file and discards the rest (it currently reads only external
subsets).  Is there any advantage to working only with external subsets?

There is no advantage to me in working with external subsets except that I
can already do it :-)

	many thanks Ron.

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Wed Nov 11 23:06:35 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:26 2004
Subject: Open-source XLink library (was Re: XLink - where are we?)
In-Reply-To: <199811111622.LAA12163@hesketh.com>
References: <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981111205328.370f5328@pop3.demon.co.uk>

At 11:24 11/11/98 -0500, Simon St.Laurent wrote:
>After spending the last few months talking and talking about how amazingly
>cool XLink _could_ be, I've taken a few steps toward _doing_ things with
>XLink.  The steps aren't lovely or stupendous (yet), but I hope that they
>might represent a step forward.  The code is not yet ready for prime time,
>but the discussion on this list makes it fairly clear that there is a need
>for this kind of project.

Many thanks. I haven't had time to look at this but this seems like a
useful way of exploring what XLink can do although it's not an API or a
library. Keep it going.

I think we shall also need some XLink APIs and/or library routines to help
with some of the processing required...

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Wed Nov 11 23:06:40 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:26 2004
Subject: Oracle XML
In-Reply-To: <3649088C.3EADA703@infinet.com>
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
Message-ID: <3.0.1.16.19981111210812.366ffdf6@pop3.demon.co.uk>

At 22:46 10/11/98 -0500, Tyler Baker wrote:
>It is nice to see that they are supporting SAX as well.  I think the
question now with XML tools in regard to
>SAX is "who does not support SAX"?

Agreed - the SAXogenists on this list can take a warm feeling away.

Remember that there were people who warned us "SAX is a waste of time" -
this is a W3C activity... The same could be said of XSchema. There seems
now to be no reasons why (after testing) we shouldn't see XSchema become
widely used for authoring/editing/validating. It's there - it does a useful
job - let's see it included in all the major tools.

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Wed Nov 11 23:06:39 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:26 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.5.32.19981110221631.008ec900@amati.techno.com>
References: <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>

At 22:16 10/11/98 -0600, W. Eliot Kimber wrote:
>At 02:14 AM 11/11/98, Peter Murray-Rust wrote:
>
>>(c) it appears to require all applications to have a stylesheet - i.e.
>>there is no default display and it's therefore primarily for rendering XML
>>as text with hyperlinks.
>
>Not trying to be difficult, but how could any useful form of default
>presentation other than running everything together or making every element
>a separate block be provided by a DTD-inspecific tool?  I don't know of any
>generalized SGML tool that provides any useful sort of default styling. The
>best is Arbortext's Document Architect, which provides a sort of wizard by
>which it asks a bunch of questions and makes some informed guesses and then
>generates a style sheet that can be a reasonable starting place (it can
>also be more trouble than it's worth depending on what sort of DTD you
>happen to have).

I am probably tilting at windmills but I am attempting something like this
in JUMBO - I have about 5 approaches to styles without stylesheets.
(a) redisplay it as raw XML. Not as silly as it sounds for many documents.
(b) pretty-print it and display as XML. Extremely useful for many documents
(c) Reformat start tags as bold and add NL after PCDATA. Works pretty well
for many documents.
(d) map every element onto a Java class. 
(e) allow the user to customise some or all elements with styles. I shall
use Swing for the rendering. Then, I suppose I could write the styles out
as XSL if anyone cares.

I get the impression that many people regard the reformatting of XML
documents for human readers as the only valid thing to do with XML. It's
important, but it's not going to lead to innovation. I'd much rather see
structured *graphics* being addressed than stylesheets. Far more exciting.
- Yes I know there is movement in this area. I'd also like to see *some*
movement on 'behaviour' - how to we create an interactive document rather
than simply decide on the best way to send it to the printer (which will be
99% of the use of XSL).

	P.


>
>Cheers,
>
>E.
>--
><Address HyTime=bibloc>
>W. Eliot Kimber, Senior Consulting SGML Engineer
>ISOGEN International Corp.
>2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
>www.isogen.com
></Address>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>
>
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From peter at ursus.demon.co.uk  Wed Nov 11 23:25:34 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:26 2004
Subject: Sun XML Lib
In-Reply-To: <19981111201248.7097.qmail@hotmail.com>
Message-ID: <3.0.1.16.19981112002428.366f5ce0@pop3.demon.co.uk>

Dear XML Doubts,
	Unless I do you and your parents an injustice, "XML Doubts" is a pseudonym
(and one at variance with an apparently useful contribution to the list).
Whilst it is/was common in Past Times (e.g. "A Tangled Tale" by Lewis
Carroll) (and today in MOOs), pseudonyms aren't really appropriate for
XML-DEV.

At 12:12 11/11/98 PST, XML Doubts wrote:
>Hi,
>
>Has any one used the Sun XML library. My question is how to access the 

If your questions is about xml-ea1, yes - I have used it, but I can't
answer the question. Your approach seems reasonable.

>
>And also how do I get the text inside the "line" tag.
>This might be trivial question but I am just a beginner. So bear with 
>me.

This is a perfectly reasonable question for XML-DEV as it relates to an
Early Adopter (i.e. recently released) package. 

	P.

PS. There are no doubts about XML. It is one of the great achievements of
the human intellect.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Thu Nov 12 00:41:18 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:26 2004
Subject: Sun XML Lib
References: <19981111201248.7097.qmail@hotmail.com>
Message-ID: <364A2D74.FFF8FF0F@eng.sun.com>

XML Doubts wrote:
> 
> ....main(String args[]){
> ....
> XmlDocument doc;

(presumably, "doc" got assigned ... !)


> Element root = doc.getDocumentElement();
> System.out.println("\nRoot: "+root.getTagName());
> System.out.println("\nFirstChild:"+
>                     (root.getFirstChild()).getNodeName());
> ...
> }
> The first print statement prints the root element, but the second print
> statement prints #text which is not what I want. I want to print the
> node name.

The node is text, and the DOM spec says that its name is "#text" ...
I'd suspect it's a text node with whitespace (a blank line) if the
input is your next example.  Try printing the names of each child,
and you'll probably see "#text", "line", "#text".

The next release (no, I won't say when!) should make it easier to
ignore whitespace that you really don't want to see, but which the
XML spec requires you to be able to see.  (Like that blank line.)


> Like for example in the XML file
> <?xml version="1.0"?>
> <poem>
> <line>Roses are red,</line>
> </poem>
> 
> The first print statement prints "poem"
> The second print statement prints #text.
> I want "line" to be printed.

You'll need to get the first node that's an element, rather than
the first node ... since the first node is whitespace.


> And also how do I get the text inside the "line" tag.

Get the (element) node whose name is "line".  Get its children.


> This might be trivial question but I am just a beginner. So bear with
> me.
> 
> Can anyone help.

These questions relate to DOM -- you'd surely have the same questions
with any DOM implementation!  Sun's package has no tutorial as yet,
but there are probably some on the network somewhere.

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


From Jon.Bosak at eng.Sun.COM  Thu Nov 12 02:01:41 1998
From: Jon.Bosak at eng.Sun.COM (Jon Bosak)
Date: Mon Jun  7 17:06:26 2004
Subject: XML and IE5 beta PR2
Message-ID: <199811120156.RAA25112@boethius.eng.sun.com>

[Paul Spencer:]

| I agree that the current IE5 implementation of XSL only does tag
| transformation. However, unless I have misunderstood CSS, I don't think
| your conclusion follows.
| 
| I have used IE5 XSL to do reasonably complex formatting of XML
| documents, including taking elements out of order, and displaying images
| (URL in the XML) with hyperlinks to documents (also with their URL in
| the XML). With a bit of judicious pre-processing of the XML using the
| DOM, I also display another image a number of times according to a
| number in the XML document.

That's not complex.  Complex is multiple columns, interleaved column
sets with multiple text flows, footnote zones, synchronized
marginalia, math formatting, mixed vertical and horizontal writing
directions -- in other words, the stuff you need in order to do
genuinely internationalized automated print publishing.

The goal is to have a single language that, once mastered, can be used
for any kind of formatting -- a language powerful enough to support
the high-quality automated layout of any amount of material that
conforms to a given DTD or document schema and modular enough to share
the bulk of a complex stylesheet across both print and online
versions.

Only when you have a single stylesheet language that can replace the
proprietary style and layout formats of programs like Quark Express,
FrameMaker, PageMaker, and Word will you be able to achieve completely
functional and transparent document interchange across applications.
And only when you have a language equally capable of supporting both
print and online display will you be able to build the common training
infrastructure that can create the shared set of human resources
needed for media-independent publishing in the next century.

That language must be primarily declarative, so that stylesheets can
be interchanged between different interactive stylesheet editors, and
it must be able to scale from a one-off memo on up to the Yellow
Pages, the New York Times, and the L. L. Bean catalogue -- both the
online and print versions.  A language that supports only the
production of HTML can't do that.

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


From ckthum at krdl.org.sg  Thu Nov 12 02:44:06 1998
From: ckthum at krdl.org.sg (Thum Ching Kuan)
Date: Mon Jun  7 17:06:26 2004
Subject: Sun XML Lib
In-Reply-To: <19981111201321.2085.qmail@hotmail.com>
Message-ID: <Pine.GSO.4.02.9811120925210.613-100000@civet>

> Hi,
> 
> Has any one used the Sun XML library. My question is how to access the 
> child nodes from the root. 
> I have tried
> 
> ....main(String args[]){
> ....
> XmlDocument doc;
> Element root = doc.getDocumentElement();
> System.out.println("\nRoot: "+root.getTagName());
> System.out.println("\nFirstChild:"+
>                     (root.getFirstChild()).getNodeName());
> ...
> }
> The first print statement prints the root element, but the second print 
> statement prints #text which is not what I want. I want to print the 
> node name.

	You can use TreeWalker in the Sun XML lib to access a node by its
name.  If you want to traverse the DOM tree, you have to handle the white
space.  Try to implement a recursive method and print out all the child
nodes with its value, take a look at IBM XML4J example.

	For your case,
try
	Node sibling = root.getFirstChild();
	sibling = sibling.getNextSibling();

System.out.println((sibling=sibling.getNextSibling.getFirstChild()).getNodeValue());

You should be able to see "Roses are red,"
now.

cheers,
Thum


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Thu Nov 12 03:06:30 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:26 2004
Subject: ID attribute defaults
In-Reply-To: <3.0.5.32.19981111144155.010ea4d0@nexus.polaris.net>
References: <3.0.32.19981111091752.00b4fdf0@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111204941.009bc9d0@amati.techno.com>

At 02:41 PM 11/11/98 -0500, John E. Simpson wrote:

>What am I missing? Is there some way both to use ID/IDREF *and* not require
>the document author to supply IDs on her own?

It's my personal feeling that the inability to provide defaults for ID,
IDREF(S), and ENTITY(IES) attributes is a bug (in SGML unavoidably
inherited by XML).  Document type designers should be able choose for
themselves what does and doesn't make sense in their applications.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Thu Nov 12 03:06:32 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:26 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
References: <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981111210459.009ba510@amati.techno.com>

At 09:03 PM 11/11/98, Peter Murray-Rust wrote:

>I am probably tilting at windmills but I am attempting something like this
>in JUMBO - I have about 5 approaches to styles without stylesheets.
>(a) redisplay it as raw XML. Not as silly as it sounds for many documents.
>(b) pretty-print it and display as XML. Extremely useful for many documents
>(c) Reformat start tags as bold and add NL after PCDATA. Works pretty well
>for many documents.
>(d) map every element onto a Java class. 
>(e) allow the user to customise some or all elements with styles. I shall
>use Swing for the rendering. Then, I suppose I could write the styles out
>as XSL if anyone cares.

I'm so focused on formatted presentation of the *content* I didn't think
about these options. The first three sound quite reasonable. The last two
are no different from requiring a style sheet--someone still has to provide
a per-document or document type definition of what the styling should
be--whether you use Jave code or DSSSL specs or XSL doesn't matter--the
task is the same.

>- Yes I know there is movement in this area. I'd also like to see *some*
>movement on 'behaviour' - how to we create an interactive document rather
>than simply decide on the best way to send it to the printer (which will be
>99% of the use of XSL).

There is the ISMID (Interchange Standard for Modifiable Interactive
Documents) that is being developed in SC34 of ISO/IEC JTC1. It's goal is to
be a relatively simple application that lets you define more or less
procedural behaviors for information objects (which could be XML documents
or components thereof). It's still being firmed up, but it seems reasonably
promissing.  I know the editors would certainly be interested in review and
comment.  We've been reviewing the latest draft this week during the ISO
meeting.  You can find the latest draft at
<http://www.ornl.gov/sgml/sc34/document/7.htm>.  As a reviewer, I've asked
the editors to do a few things that will make the spec a bit more XML
friendly.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Thu Nov 12 04:58:13 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:27 2004
Subject: Endtag attributes
References: <36474321.DE4EA5A3@toolsmiths.se> <wk67cna6cp.fsf@ifi.uio.no>
Message-ID: <364A665A.EA3B428D@technologist.com>

Lars Marius Garshol wrote:
> 

> The only pro I can think of is pretty far-fetched:
> 
>  - might be easier to generate markup from some kinds of applications,
>    since attribute values would not have to be determined until after
>    the element contents had been written out

I think that optional redundant end-tag attributes would be useful, for
the same reason that the redundant end-tag GI (which should be optional)
is useful:

<SECTION ID="Intro">
   <SECTION AUTHOR="Paul" ID="Why.XML">
       <SECTION ID="XML.Strengths">
	10,000 lines of text
       </SECTION ID="XML.Strengths">
       <SECTION ID="HTML.Weaknesses">
   	 10,000 lines of text
       </SECTION ID="HTML.Weaknesses">
   </SECTION ID="Why.XML">
   <SECTION ID="XML.Tools">
   10,000 lines of text
   </SECTION ID="XML.Tools">
</SECTION ID="Intro">

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

At today's pop doubling rates, in 100 years there will be 20 billion
people, more than enough to fill the earth. In 300 years, we will have
filled up 16 earth-sized planets (roughly, our solar system). In 2300
years we will have filled up 200 billion earth-sized planets (roughly,
our galaxy). Only one technology can save us: birth control.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Thu Nov 12 05:01:55 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:27 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML 
 Application
References: <3641FCE4.61D46D15@locke.ccil.org>
Message-ID: <364A666C.4D938DD4@technologist.com>

John Cowan wrote:
> 
> 10. An XML processor (necessarily a non-validating one) that does
> not include the replacement text of an external parsed entity
> in place of an entity reference must notify the application that
> it recognized but did not read the entity (4.4.3)  [SAX does not
> provide for this]

I think David agrees with me that XML processors do not have enough
information to make the decision about whether entity references should be
expanded or not. If an author wants an inter-entity reference that can be
expanded "lazily", they should use XLink and describe the behaviour they
want in a stylesheet.

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

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Thu Nov 12 05:02:22 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:27 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML 
 Application
References: <3641FCE4.61D46D15@locke.ccil.org>
Message-ID: <364A6634.4E060F06@technologist.com>

John Cowan wrote:
> 
> 10. An XML processor (necessarily a non-validating one) that does
> not include the replacement text of an external parsed entity
> in place of an entity reference must notify the application that
> it recognized but did not read the entity (4.4.3)  [SAX does not
> provide for this]

I think David agrees with me that XML processors do not have enough
information to make the decision about whether entity references should be
expanded or not. If an author wants an inter-entity reference that can be
expanded "lazily", they should use XLink and describe the behaviour they
want in a stylesheet.

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

"The new revolutionaries believe the time has come for an aggressive 
move against our oppressors. We have established a solid beachhead 
on Friday. We now intend to fight vigorously for 'casual Thursdays.'
  -- who says America's revolutionary spirit is dead?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jjc at jclark.com  Thu Nov 12 05:54:52 1998
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:06:27 2004
Subject: XML and IE5 beta PR2
References: <000001be0c0b$e89672a0$020110ac@office> <36473C9A.2E09D648@eng.sun.com>
Message-ID: <364A77D3.22BF85E7@jclark.com>

David Brownell wrote:
> 
> Paul Spencer wrote:
> >
> > Mind you, I don't think MS is correctly implementing the August 18
> > [XSL] draft, but that is another matter, and I could be wrong.
> 
> With "xsl:eval", "xsl:script" and many other proprietary extensions,
> yet without even "xsl:process-children", I think you're clearly right.
> W3C's XSL pattern syntax is there, but not a lot else.

In fairness to Microsoft, I think it should be pointed out that some of
the differences between what Microsoft has implemented and the Aug 18
draft correspond to changes that have been decided by the XSL WG since
the Aug 18 draft.

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


From peter at ursus.demon.co.uk  Thu Nov 12 07:56:24 1998
From: peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun  7 17:06:27 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are we?)
In-Reply-To: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
References: <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.1.16.19981112085340.36af5dac@pop3.demon.co.uk>

At 21:04 11/11/98 -0600, W. Eliot Kimber wrote:

>I'm so focused on formatted presentation of the *content* I didn't think
>about these options. The first three sound quite reasonable. The last two

Thanks :-). I think there is a "feature" of the XML community that many of
the founders are heavily focussed on conventional paper-based formatting.
Jon Bosak's recent mail puts that very clearly. The design features of
Hybrick are also clearly geared towards that - it looks like a non-trivial
task for me to adapt it to chemical reactions, for example. [I may be
wrong, but without source and the very restrictive license I can't judge]. 

Nothing wrong with this view. People (even me) want to read paper. But I
certainly feel that almost everything else is seen as lower priority than
the holy grail of high-performance text formatting. And the policy makers
in the W3C community are very much oriented towards paper-like operations. 

2 years since the conception of XML and we cannot (with general agreement
on interoperability):
	- send a hyperlink over the wire
	- send a button over the wire
	- since a date over the wire
	- send a structured graphic over the wire
	
We *can* send a mathematical equation. 

This may sound unfair and - yes, I know - there are many things in the
pipeline but IMO the innovation that we saw 18 months ago is disappearing.
Essentially the vision of the XML process is often something like:
server-side:
	original data -> XML ->+XSL-> output format (e.g. PDF/HTML/PS)

PDF/HTML is sent over the wire. The PS is printed and put in the mail.

client-side:
	reader receives a dumb document

Yes, I know that there are XML-aware browsers and client side stylesheets
but the purpose of what Jon was describing is often so they can send it
straight to their local printer.

>are no different from requiring a style sheet--someone still has to provide
>a per-document or document type definition of what the styling should
>be--whether you use Jave code or DSSSL specs or XSL doesn't matter--the
>task is the same.

Nope. In Java the task for me is:
	- to identify how to map Java classes onto elements. I haven't followed
XSL but I assume it gives little or no help. 
	- how to create different on-line displays interactively. I'd like to
insert buttons where there are hyperlinks, for example. Is all that in XSL.

My concern about the word "stylesheet" is that it restricts our vision of
what is possible. And that the excitement of the whole XML effort will
disappear. Yes - I know XML is meant to be boring as many people have said
and sending pseudo-paper over the wire is not - yet - very exciting.

I am making the assumptions that a large  number of XML documents will
never have stylesheets. Very few do at the moment. So JUMBO was designed
with the idea that we will have to cope with documents **that do not have
stylesheets**. The current mainstream view - as exemplified by Hybrick -
seems to be that such a document is broken. I don't accept this :-) Maybe I
am just a niche player but it's a very large and exciting niche and anyone
who is interested is welcome to play :-)

>
>>- Yes I know there is movement in this area. I'd also like to see *some*
>>movement on 'behaviour' - how to we create an interactive document rather
>>than simply decide on the best way to send it to the printer (which will be
>>99% of the use of XSL).
>
>There is the ISMID (Interchange Standard for Modifiable Interactive
>Documents) that is being developed in SC34 of ISO/IEC JTC1. It's goal is to
>be a relatively simple application that lets you define more or less
>procedural behaviors for information objects (which could be XML documents
>or components thereof). It's still being firmed up, but it seems reasonably
>promissing.  I know the editors would certainly be interested in review and
>comment.  We've been reviewing the latest draft this week during the ISO
>meeting.  You can find the latest draft at
><http://www.ornl.gov/sgml/sc34/document/7.htm>.  As a reviewer, I've asked
>the editors to do a few things that will make the spec a bit more XML
>friendly.

Does this imply that it's not XML-compatible at present? Because I suspect
people will get increasingly frustrated with SGML-over-the-wire (e.g.
Hybrick at present) because they don't know how to manage declarations and
catalogs.

	P.

>
>Cheers,
>
>Eliot
>--
><Address HyTime=bibloc>
>W. Eliot Kimber, Senior Consulting SGML Engineer
>ISOGEN International Corp.
>2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
>www.isogen.com
></Address>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>
>
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From RJA at arpsolutions.demon.co.uk  Thu Nov 12 08:21:57 1998
From: RJA at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:27 2004
Subject: Oracle XML
Message-ID: <012c01be0e15$91bae7c0$c5010180@p197>

>Agreed - the SAXogenists on this list can take a warm feeling away.
SAX is great.  I've now got an ActiveX version and a C++ version going and I
really love it. ( not 100% yet )

For interest, have there been any developments of a 'lower level' SAX to
expose DTD info too ?

In my XML toolkit I want to expose events that enable the caller to use
information from the DTD however *they* want.   I will of course provide a
high level interface too, but it would be nice to have a stream of events
like:

startDocType
  startEntity
  startElementDef
  endElementDef
  startAttribDef
    startAttribElementSeq
    endAttribElementSeq
    startAttribElementSeq
    endAttribElementSeq
  endAttribDef
  endEntity
endDoctype

You get the basic idea.

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From alberto.reggiori at jrc.it  Thu Nov 12 08:27:46 1998
From: alberto.reggiori at jrc.it (Alberto Reggiori)
Date: Mon Jun  7 17:06:27 2004
Subject: XML for Network Topology
References: <v04011701b26f94eb473b@[128.253.245.66]>
Message-ID: <364A9BEA.E9E84459@jrc.it>

Joel Bender wrote:
> 
> I'm interested in (1) a DTD for networking, specifically to describe a
> topology of networks, routers, ports, etc.  If one doesn't already exist,
> contact me and we'll form a splinter group to create one (my guess would be
> to start with SNMP data and go from there).
> 

Have a look at http://www.dmtf.org/cim/cim_xml/index.html

They are working at a meta-meta-model level ;-)


regards


Alberto

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From graham.moore at dpsl.co.uk  Thu Nov 12 09:08:15 1998
From: graham.moore at dpsl.co.uk (Graham Moore)
Date: Mon Jun  7 17:06:27 2004
Subject: XLink - where are we? [tiny amount o
Message-ID: <TFSHEECZ@dpsl.co.uk>>

Eliot wrote

>The last two [java class for elements / swing classes] are no different 
from requiring a style sheet--someone still has to
> provide
> a per-document or document type definition of what the styling should
> be

The functional binding / class => element could be done as a default. Look 
in the location where the document was acquired from using the element name 
as the class name. It would just work, with no additional configuration 
files. If no class exists then the node is just a node.

cheers,

graham.

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


From M.H.Kay at eng.icl.co.uk  Thu Nov 12 09:48:44 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:27 2004
Subject: XLink - where are we? [tiny amount of frustration]
Message-ID: <00c201be0e21$af6209a0$1b11e391@mhklaptop.bra01.icl.co.uk>


>- Yes I know there is movement in this area. I'd also like
to see *some*
>movement on 'behaviour' - how to we create an interactive
document rather
>than simply decide on the best way to send it to the
printer (which will be
>99% of the use of XSL).


And this reflects a lingering concern I have about XLink,
which is that it is putting display-time behaviour into the
XML document rather than into the stylesheet. I'm not
convinced that XLink is defining relationships at a high
enough level of abstraction, and I'd prefer to see work on
interactive behaviour happen in the XSL world.

In particular, I am really uncomfortable with the one-to-one
mapping of stored XML documents to "units of display". I
think the presentation facilities (stylesheets and hyperlink
browsing) should be independent of the granularity of
storage. I tried to illustrate this concept with my HTML
rendition of the New Testament
 http://www.wokchorsoc.freeserve.co.uk/bible-nt/index.html )
where one XML document is rendered as many HTML documents
within a navigable frameset. Here of course there are no
XLink's at all: the document is purely hierarchic, and the
interactive behaviour is inferred from the intrinsic
structure of the XML.

I don't see who in the XSL / XLink world is trying to make
such a rendition easy to define. Conceptually, I'm sure it
can be done by using frames as flow objects: there is, of
course, the little problem of the "unit of download" if you
want to do it client-side. (I did it, of course, with a
server-side SAXON application).

To put things another way, if I'm going to have to
pre-process my corpus by splitting it into lots of linked
page-sized chunks to make it browsable, I might as well
render those chunks in HTML while I'm about it.

Ralph - it would be nice to see what Hytime can achieve with
the New Testament example.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Philippe.Le_Hegaret at sophia.inria.fr  Thu Nov 12 09:54:22 1998
From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret)
Date: Mon Jun  7 17:06:27 2004
Subject: Oracle XML
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
Message-ID: <364AB030.EFAC2ADE@sophia.inria.fr>

K. Travis Walsh wrote:
> 
> Oracle officially anounced today it's XML strategy.
> 
> For those of you who didn't know there is a java parser built into this
> new release of Oracle 8i.

  Like netscape, They can't write well-formed XML document.

  <?xml version="1.0"> is not a well-formed XML document.

http://www.oracle.com/xml/documents/xml_twp/ (Figure 2)

Philippe.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Thu Nov 12 09:57:53 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:27 2004
Subject: XLink - where are we? [tiny amount o
References: <TFSHEECZ@dpsl.co.uk>>
Message-ID: <364AAE1E.84704C93@eng.sun.com>

Graham Moore wrote:
> 
> Eliot wrote
> 
> > The last two [java class for elements / swing classes] are no different
> > from requiring a style sheet--someone still has to provide
> > a per-document or document type definition of what the styling should
> > be
> 
> The functional binding / class => element could be done as a default. Look
> in the location where the document was acquired from using the element name
> as the class name. It would just work, with no additional configuration
> files. If no class exists then the node is just a node.

That doesn't seem sufficient to me.  What's the package name?  What
about classes that should represent multiple element types?  What about
the different semantics associated with different namespaces?  Suppose
you want the element and class names to be different, perhaps because
you and your users work with different natural languages?  (And I'll
confess to having deferred the homework to finding out exactly how
XML names and Java names differ!  I'd expect them not to be the same.)

The model I'm working with right now does include a mapping of name
to class, but it's not direct (e.g. can be many to one) and is aware
of namespaces.  It can be statically configured (e.g. an XML element
containing mappings -- embedded, or in a separate document) as well
as algorithmically configured (i.e. a factory class).

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


From graham.moore at dpsl.co.uk  Thu Nov 12 11:18:14 1998
From: graham.moore at dpsl.co.uk (Graham Moore)
Date: Mon Jun  7 17:06:27 2004
Subject: Back to XObjects was XLink - where a
Message-ID: <TFSIXERP@dpsl.co.uk>>


 - Dave wrote

>>>>>>>>>

That doesn't seem sufficient to me.  What's the package name?  What
about classes that should represent multiple element types?  What about
the different semantics associated with different namespaces?  Suppose
you want the element and class names to be different, perhaps because
you and your users work with different natural languages?  (And I'll
confess to having deferred the homework to finding out exactly how
XML names and Java names differ!  I'd expect them not to be the same.)

The model I'm working with right now does include a mapping of name
to class, but it's not direct (e.g. can be many to one) and is aware
of namespaces.  It can be statically configured (e.g. an XML element
containing mappings -- embedded, or in a separate document) as well
as algorithmically configured (i.e. a factory class).

<<<<<<<<<<<<<

Its completely insufficient. But it is a base level at which things will 
work. The package name can be ingnored as classes dont have to be in a 
package. (bad idea - but allowed) or a default could be used.

The model I have working uses XML config files to specfiy the binding and 
allows the specification of more powerful delegation structures than simply 
inheriting from the w3c.node.

I guess my point really comes back to having a variety of interfaces on the 
domBuilder that allow for as much or as little binding configuration as 
required. I think we need to pick up the XObjects discussion on the 
domBuilder interfaces. If this sounds like a good idea I'll sift through the 
contributions of interfaces / part interfaces and present those as a 
starting point?

graham.

gdm@dpsl.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov 12 12:38:23 1998
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:06:27 2004
Subject: XLink - where are we? [tiny amount o
References: <TFSHEECZ@dpsl.co.uk>> <364AAE1E.84704C93@eng.sun.com>
Message-ID: <364AD6E0.E7B489A2@mecomnet.de>

David Brownell wrote:
> 
> Graham Moore wrote:
> >
> > Eliot wrote
> >
> > > The last two [java class for elements / swing classes] are no different
> > > from requiring a style sheet--someone still has to provide
> > > a per-document or document type definition of what the styling should
> > > be
> >
> > The functional binding / class => element could be done as a default. Look
> > in the location where the document was acquired from using the element name
> > as the class name. It would just work, with no additional configuration
> > files. If no class exists then the node is just a node.
> 
> That doesn't seem sufficient to me.  What's the package name?

a mapping from the namespace name. (java packages may require an intermediate)

> What about classes that should represent multiple element types?

specialize the class appropriately

> What about the different semantics associated with different namespaces?

that's what packages are for.

> Suppose you want the element and class names to be different, perhaps because
> you and your users work with different natural languages?

support an architectural attribute, with appropriate defaults in the attribute definitions.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Thu Nov 12 14:31:12 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:27 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <00c201be0e21$af6209a0$1b11e391@mhklaptop.bra01.icl.co.uk>
Message-ID: <3.0.5.32.19981112082831.008ce3f0@amati.techno.com>

At 09:49 AM 11/12/98 -0000, Michael Kay wrote:

>To put things another way, if I'm going to have to
>pre-process my corpus by splitting it into lots of linked
>page-sized chunks to make it browsable, I might as well
>render those chunks in HTML while I'm about it.
>
>Ralph - it would be nice to see what Hytime can achieve with
>the New Testament example.

>From a HyTime standpoint, it's purely a matter of presentation style and
browser implementation.

For example, the HyBrowse HyTime browser from TechnoTeacher was implemented
so that whatever you link to is always presented in isolation whenever you
traverse to it. So if you link to a particular chapter, that's all you'll
see when you follow the link.

But this behavior is not required (or even suggested) by the HyTime
standard--it's a decision the implementors of HyBrowse made, for whatever
reason.  They could just as easily have made the opposite decision, or,
like DynaText, given you a way to define the rendering scope in the style
sheet.

The communication between client and server in a generalized hypermedia
environment cannot be standardized to the degree that a given link or form
of address defines or implies a particular communication sequence.  The
most you can do is provide a way for clients to communicate requirements to
servers and provide a common *abstraction* for the data being communicated
so that the appropriate amount of data can be transmitted, regardless of
whether or not it happens to be a single XML document.  Groves are one such
abstraction.  The "fragment interchange" group is trying to solve the same
problem by enabling the transimission of syntactic data chunks that are not
complete documents. While this is a useful practical shortcut, it cannot
replace the transmission of document abstractions in the general case (this
is because there are some processes that require knowledge of or access to
the entire document in order to complete rendition, although it's unlikely
these types of processes will be used for Web-based applications very often).

So, HyTime can't offer any solution to the problem *by itself*, although it
provides a pretty solid framework in which a solution could be defined. But
the solution has to come from client and server providers because it is
ultimately a problem of client-to-server communication, not hyperlink and
address representation in documents (which is all HyTime and Xlink talk
about).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Thu Nov 12 14:31:14 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:28 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are
  we?)
In-Reply-To: <3.0.1.16.19981112085340.36af5dac@pop3.demon.co.uk>
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981112081552.0092d600@amati.techno.com>

At 08:53 AM 11/12/98, Peter Murray-Rust wrote:
>>are no different from requiring a style sheet--someone still has to provide
>>a per-document or document type definition of what the styling should
>>be--whether you use Jave code or DSSSL specs or XSL doesn't matter--the
>>task is the same.
>
>Nope. In Java the task for me is:
>	- to identify how to map Java classes onto elements. I haven't followed
>XSL but I assume it gives little or no help. 
>	- how to create different on-line displays interactively. I'd like to
>insert buttons where there are hyperlinks, for example. Is all that in XSL.

But given that your browser provides a way to do the association, the task
is to *create the Java classes*, which is conceptually identical to
creating a style rule in a DSSSL or XSL specification, although the details
of the specification are of course different.

Style sheets are nothing more than a mostly-declarative form of program. 

Here's how I would insert a "button" into the display of a document using
DSSSL and HyBrick:

(element simple  ; Rule for any Xlink <simple> element
  (make link destination: (resolve-location-address 
                            (attribute-string "HREF" (current-node)))
    (make external-graphic entity-system-id: "buttons/clickhere.gif"
                           notation-system-id: ""))))


With Java, I might have a button class that I map elements of type "simple"
to, but the result would be indistinguishable from the above (all other
things being equal).

Providing a sexier type of button would require support within the
presenation system for them.  For example, say my online DSSSL renderer
supports program objects as a notation for external graphics.  I could do
this:

(element hyperlink
  (make link destination: (resolve-location-address 
                            (attribute-string "HREF" (current-node)))
    (make external-graphic entity-system-id: "{BACD-0000-0000-BCDEF-00}"
                           notation-system-id: "WINCOM"))))

Now my button will be a program object rather than a static graphic, but
notice that the style definition has not otherwise changed--I've just taken
advantage of some facility of my presentation system.

Another alternative would be to define a new flow object class that
provides the interactive features you want. Say, for example, you want a
button that will appear to push.  We (as a community or as a set of
developers) could define a new flow object class called, for example,
"interactive-button":

(element hyperlink
  (make link destination: (resolve-location-address 
                            (attribute-string "HREF" (current-node)))
    (make interactive-button 
       behavior: 'push  ; Alternatives might be rollover, flash, etc.
       image-system-id: "buttons/clickhere.gif")))

Now we've abstracted the idea of "button" in a way that can be reasonably
interchanged and implemented in a variety of ways.  The degree to which it
is interchangable is the degree to which different providers of DSSSL-based
rendering systems implement it.

I've used DSSSL syntax because that's what I know, but the same approach
should apply to XSL as well (at least to the degree that XSL supports the
definition of new flow object classes, which it may or may not, I don't know).

Cheers,

E.



--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Thu Nov 12 14:31:17 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:28 2004
Subject: XLink - where are we? [tiny amount o
In-Reply-To: <TFSHEECZ@dpsl.co.uk>>
Message-ID: <3.0.5.32.19981112081655.0089bbf0@amati.techno.com>

At 08:56 AM 11/12/98 +0000, Graham Moore wrote:
>Eliot wrote
>
>>The last two [java class for elements / swing classes] are no different 
>from requiring a style sheet--someone still has to
>> provide
>> a per-document or document type definition of what the styling should
>> be
>
>The functional binding / class => element could be done as a default. Look 
>in the location where the document was acquired from using the element name 
>as the class name. It would just work, with no additional configuration 
>files. If no class exists then the node is just a node.

My point is that *someone has to write the classes*.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Thu Nov 12 14:34:40 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:28 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are
  we?)
In-Reply-To: <3.0.1.16.19981112085340.36af5dac@pop3.demon.co.uk>
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981112075504.008d5b10@amati.techno.com>

At 08:53 AM 11/12/98, Peter Murray-Rust wrote:
>Does this imply that it's not XML-compatible at present? Because I suspect
>people will get increasingly frustrated with SGML-over-the-wire (e.g.
>Hybrick at present) because they don't know how to manage declarations and
>catalogs.

It's perfectly XML compatible, but the draft as printed provides
architectural DTD declarations that assume the use of typical SGML features
(i.e., markup minimization) and does not provide an alternative set of
declarations that restricts itself to those SGML features used by XML.
Obviously anyone could create those declarations (as I did for HyTime in
developing my PHyLIS tool), but there's no reason for the editors not to
provide it directly given that it's an obvious requirement (and in fact, it
should have always been the policy that two forms of architectural
declarations be provided, one for SGML declarations that allow markup
minimization and one for SGML declarations that do not, which is the key
difference {whether or not start and end tag parameters are prohibited}). 

The concepts defined in the standard are independent of syntax.  If you're
simply implementing the semantics but not using true architectural
processing, then you don't care about the details of the declaration syntax
of the architectural meta-DTDs, using them simply as documentation and not
as processible data sets.

Remember that when defining any sort of SGML application (that is, an
application of SGML, not software that processes SGML), the *ONLY* thing
that would make it not usable with XML documents would be the requirement
that docments use an SGML feature that XML does not provide. As data
entities is the only feature of SGML not provided by XML that also has
significant *semantic* utility (as opposed to being a syntactic convenience
like markup minimization or the LINK feature), you'd have to go out of your
way to make your application not XML compatible.  And in any case, you can
get by without data attributes, although it's clumsy and suboptimal.

Cheers,

E.

--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Thu Nov 12 14:42:55 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:28 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are we?)
References: <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca> <3.0.1.16.19981112085340.36af5dac@pop3.demon.co.uk>
Message-ID: <364AEBA5.C08FED15@technologist.com>

Peter Murray-Rust wrote:
> 
> Nope. In Java the task for me is:
>         - to identify how to map Java classes onto elements. I haven't followed
> XSL but I assume it gives little or no help.
>         - how to create different on-line displays interactively. I'd like to
> insert buttons where there are hyperlinks, for example. Is all that in XSL.
> 
>...
> 
> I am making the assumptions that a large  number of XML documents will
> never have stylesheets. Very few do at the moment. So JUMBO was designed
> with the idea that we will have to cope with documents **that do not have
> stylesheets**. 

If you find a way to map elements to Java classes so that Java classes
provide behaviour for elements, then you will have *made a stylesheet* and
you will have used Java as your stylesheet language.

> The current mainstream view - as exemplified by Hybrick -
> seems to be that such a document is broken. I don't accept this :-) 

I'm not sure that I would call HyBrick "mainstream". It is cool, but it
doesn't represent the Microsoft/Netscape establishment's view of how the
world should work. 

Anyhow, HyBrick's view is that if HyBrick cannot be taught to process the
document (through DSSSL, HyBrick's stylesheet/extension language) then the
document is useless for use in HyBrick. Likely the same holds true for
Jumbo. All you can do without some kind of functional specification
("stylesheet) is display an undifferentiated tree view (or, with RDF, a
more arbitrary graph view). 

If that's all you want to do, you don't need stylesheets. HyBrick clearly
isn't intended to be a tree viewer, however.

> Does this imply that it's not XML-compatible at present? Because I suspect
> people will get increasingly frustrated with SGML-over-the-wire (e.g.
> Hybrick at present) because they don't know how to manage declarations and
> catalogs.

Although I don't know anything about ISMID, I presume from the sentence
below that ISMID doesn't exist yet:

> >There is the ISMID (Interchange Standard for Modifiable Interactive
> >Documents) that is being developed in SC34 of ISO/IEC JTC1. It's goal is to

The current *draft* is not XML friendly, I guess. Most likely there will
be no tools for people to get frustrated with until there is a standard
and that standard will most likely be XML friendly.

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

At today's pop doubling rates, in 100 years there will be 20 billion
people, more than enough to fill the earth. In 300 years, we will have
filled up 16 earth-sized planets (roughly, our solar system). In 2300
years we will have filled up 200 billion earth-sized planets (roughly,
our galaxy). Only one technology can save us: birth control.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From papresco at technologist.com  Thu Nov 12 14:53:19 1998
From: papresco at technologist.com (Paul Prescod)
Date: Mon Jun  7 17:06:28 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are we?)
References: <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca> <3.0.1.16.19981112085340.36af5dac@pop3.demon.co.uk>
Message-ID: <364AEEFB.7BC122B0@technologist.com>

Peter Murray-Rust wrote:
> 
> Nothing wrong with this view. People (even me) want to read paper. But I
> certainly feel that almost everything else is seen as lower priority than
> the holy grail of high-performance text formatting. And the policy makers
> in the W3C community are very much oriented towards paper-like operations.

I'm not sure where you get this impression. Let's consider the specs that
have been completed since XML:

Document Object Model (DOM) Level 1 
Synchronized Multimedia Integration Language (SMIL) 1.0 Specification 
PICS Signed Labels (DSig) 1.0 Specification
Cascading Style Sheets, level 2 (CSS2) Specification 
Mathematical Markup Language (MathML) 1.0 Specification 

Of these, only one even specifically *addresses* the needs of paper-like
operation (CSS). And CSS is for HTML, not XSL. Another is useful for print
only as a side effect (MathML). The rest have essentially nothing to do
with print, other than through their application to all of XML.

> 2 years since the conception of XML and we cannot (with general agreement
> on interoperability):
>         - send a hyperlink over the wire
>         - send a button over the wire
>         - since a date over the wire
>         - send a structured graphic over the wire
> 
> We *can* send a mathematical equation.

You forget that using only existing standards, we also cannot send an XML
paragraph, or a bolded word in way that can display in two browsers. We
can downtranslate to HTML, but you can do that with hyperlinks and buttons
also.

> This may sound unfair and - yes, I know - there are many things in the
> pipeline but IMO the innovation that we saw 18 months ago is disappearing.

My impression is the opposite. Two years ago, we were arguing about how to
handle whitespace.

> Yes, I know that there are XML-aware browsers and client side stylesheets
> but the purpose of what Jon was describing is often so they can send it
> straight to their local printer.

I don't understand your point. Why would Jon go to all of the effort of
pushing the XML effort to re-solve problems that he had solved three years
ago? I'd be surprised if Sun is even going to bother disrupting existing
systems for "XML compliance" in the near future. Nobody in the XML world
is trying to recreate SGML and DSSSL. Why would we bother?

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

At today's pop doubling rates, in 100 years there will be 20 billion
people, more than enough to fill the earth. In 300 years, we will have
filled up 16 earth-sized planets (roughly, our solar system). In 2300
years we will have filled up 200 billion earth-sized planets (roughly,
our galaxy). Only one technology can save us: birth control.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sroth at radsys.com  Thu Nov 12 15:00:12 1998
From: sroth at radsys.com (Roth, Scott)
Date: Mon Jun  7 17:06:28 2004
Subject: Tools for creating Style Sheets???
Message-ID: <5FAFB2A5D7B2D111ACEA0060972027CE186386@RADSYS_EXCH>

Does anyone recommend a tool for creating style sheets or know of any good
tutorials to create them??
I am getting ready to learn how to make them I would like to know the best
way to accomplish it.


Thanks

Scott Roth

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dante at mstirling.gsfc.nasa.gov  Thu Nov 12 15:05:54 1998
From: dante at mstirling.gsfc.nasa.gov (Dante Lee)
Date: Mon Jun  7 17:06:28 2004
Subject: Inputting in image
Message-ID: <Pine.LNX.3.95.981112105437.28481A-100000@mstirling.gsfc.nasa.gov>

Does anybody know how exactly you input an image into an XML document?
Do you use the LOGO tag?


______________________________________________________________

      d                    t                 l
      d                    t                 l
      d                ttttttttt             l
 dddddd   aaaa    nnnn     t      eee        l    eee    eee
d     d  a    a  n    n    t     e   e       l   e   e  e   e
d     d  aaaaaa  n    n    t     eeeee       l   eeeee  eeeee
d     d  a    a  n    n    t     e           l   e      e
ddddddd  a    a  n    n    t     eeeee       l   eeeee  eeeee

_______________________________________________________________

	          Dante M. Lee    Code 588
        	NASA/GSFC Greenbelt MD 20771
 	Voice = 301-521-1077   Bldg = 23  Rm = W415 
 	  Email = dante@mstirling.gsfc.nasa.gov
                  dante4@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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From laurie.mann at ansys.com  Thu Nov 12 15:14:09 1998
From: laurie.mann at ansys.com (Laurie Mann)
Date: Mon Jun  7 17:06:28 2004
Subject: Tools for creating Style Sheets???
Message-ID: <7D70697C0E38D111B4FF080036B39A038C72A7@ntdevexc.ansys.com>

> From:	Roth, Scott [SMTP:sroth@radsys.com]
	>Does anyone recommend a tool for creating style sheets or know
of any good
	>tutorials to create them??

	I looked at a bunch of style-sheet related sites when I was
	learning how to build them, and found the following site to
	be absolutely invaluable:

	    http://www.w3.org/Style/CSS/Test/current/index.html

	These other sites are pretty useful too:

	   http://home2.swipnet.se/~w-20547/faqs/ciwas-mFAQ.html
	      [FAQ v1.70] Welcome to
comp.infosystems.www.authoring.stylesheets

	  http://www.w3.org/TR/REC-CSS1
	    Cascading Style Sheets, level 1
	                
	http://wdvl.internet.com/Authoring/Style/Sheets/Tutorial.html
	   The WDVL: Introduction to Style Sheets

	http://www.w3.org/Style
	    Web Style Sheets

	http://www.builder.com/Authoring/CSS/table.html
	    CSS reference table

	http://server.htmlhelp.org/reference/css/stylesheets-now.html
	   Style Sheets Now

	http://style.webreview.com/glossary.html
	    CSS Resource Guide -- CSS1 Glossary

	http://www.htmlgoodies.com/ie_style.html#what
	    HTMLGoodies - style

	http://www.zeldman.com/faq_styles.html
	    Ask Doctor Web About Style Sheets

	http://webreview.com/97/05/30/feature/tutorial.html
	    What Can You Do With Style Sheets

	http://www.hwg.org/resources/faqs/cssFAQ.html
	    CSS Frequently Asked Questions

	Once you get the hang of CSS1, take a look at the
	future of stylesheets with CSS2:

	http://www.w3.org/TR/REC-CSS2
	    Cascading Style Sheets, Level 2

	http://www.w3.org/TR/WD-CSS2/page.html
	     CSS2- Paged media

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sroth at radsys.com  Thu Nov 12 15:30:23 1998
From: sroth at radsys.com (Roth, Scott)
Date: Mon Jun  7 17:06:28 2004
Subject: Good Demos of XML?
Message-ID: <5FAFB2A5D7B2D111ACEA0060972027CE186388@RADSYS_EXCH>

Ok here a I go with another favor...don't worry folks once I get up to speed
on this XML stuff I will contribute more I promise.

Now I am wondering if anybody has some good demos for XML.  I have seen
AgentSoft's XML searcher and I know about Microsoft's Auction and the stuff
on XMLu but is there any other one's out there??

thanks

Scott Roth

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Thu Nov 12 15:33:55 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:28 2004
Subject: SAX Future (was Re: Oracle XML)
In-Reply-To: <012c01be0e15$91bae7c0$c5010180@p197>
References: <012c01be0e15$91bae7c0$c5010180@p197>
Message-ID: <13898.64310.340243.918644@localhost.localdomain>

Richard Anderson writes:

 > For interest, have there been any developments of a 'lower level'
 > SAX to expose DTD info too ?

We've talked about it -- I need to be convinced that there is a big
enough demand for that (it would be useful only for very specialised
applications).  I think that the following for SAX 1.0 are probably
higher priorities:

1. A proper specification for SAX (JavaDoc just doesn't cut it).

2. A test suite for SAX conformance.

3. Canonical SAX interfaces for Perl (on top of XML:Parser) and C++.

After that, we need to decide if the benefits of a new version of SAX
outweight the enormous compatibility problems that will result.  If we 
decide that a new version is worthwhile, here's what I think will be
most important:

1. Better control/querying of parser features
   (validating/non-validating, includes/does not include external
   parameter/general entities, provides/does not provide locators, etc.).

2. A canonical interface for SAX filters (probably based on Cowan's
   work).

3. A bit more core library functionality (including constructing an
   absolute URL from a file name).

4. A new (optional) handler type for lexical information that can
   optionally be included in the DOM, such as comments and the
   document type declaration.  This will have to track the XML-Infoset 
   work, and parsers would not be required to support it.

This would all be convenient, but is it worth outdating all existing
SAX implementations just to add it?  Parser writers, for example, may
have to deal with hundreds more bug reports (each) because of people
using the wrong version of the SAX interface.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 12 15:42:14 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:28 2004
Subject: Inputting in image
In-Reply-To: <Pine.LNX.3.95.981112105437.28481A-100000@mstirling.gsfc.nasa.gov>
References: <Pine.LNX.3.95.981112105437.28481A-100000@mstirling.gsfc.nasa.gov>
Message-ID: <13899.20.109979.162731@localhost.localdomain>

Dante Lee writes:

 > Does anybody know how exactly you input an image into an XML
 > document?  Do you use the LOGO tag?

Sure.  Of course, you could also use an IMG element, a BILD element, a 
FOOBAR element, an HERESAPICTURETHATIWANTTOINCLUDEINMYDOCUMENT
element, or anything else.

XML is a way of defining document types (or vocabularies, if you
prefer), just like IP is a way of exchanging packets and ASCII is a
way of representing simple English-language text electronically.

You really want to know how to include an image in a *specific* XML
document type -- pick a document type and read its user documentation, 
or invent your own and choose any element type name you want.


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


From rbourret at ito.tu-darmstadt.de  Thu Nov 12 15:47:17 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:28 2004
Subject: SAX Future (was Re: Oracle XML)
Message-ID: <01BE0E5B.6AB4F710@grappa.ito.tu-darmstadt.de>

David Megginson wrote:

> Richard Anderson writes:
> 
>  > For interest, have there been any developments of a 'lower level'
>  > SAX to expose DTD info too ?
> 
> We've talked about it -- I need to be convinced that there is a big
> enough demand for that (it would be useful only for very specialised
> applications).

Note also that this is one of the problems schema languages were designed to solve.  If you have an XML-based schema language, then all that is needed is a parser that parses DTDs and fires SAX events in the schema language and you're done.

For most applications, this is an adequate solution.  It won't work for all applications because: (a) the schema language might not duplicate all the capabilities of the DTD and (b) the order in which the schema events are fired might not be the same as the order in which the DTD declarations occur.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 12 15:50:04 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:28 2004
Subject: Open-source XLink library (was Re: XLink - where are we?)
In-Reply-To: <3.0.1.16.19981111205328.370f5328@pop3.demon.co.uk>
References: <199811111622.LAA12163@hesketh.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <199811121547.KAA01339@hesketh.com>

At 08:53 PM 11/11/98 +0000, Peter Murray-Rust wrote:

>Many thanks. I haven't had time to look at this but this seems like a
>useful way of exploring what XLink can do although it's not an API or a
>library. Keep it going.
>
>I think we shall also need some XLink APIs and/or library routines to help
>with some of the processing required...
>
>	P.
>

Actually, it is is a library, or will be.  The demos were one-offs, but the
XLinkFilter, LinkSet, and Link classes are definitely library code - and
will hopefully be worthy of real use fairly soon.  I'm building demos
around them, which is definitely clarifying a lot of the functions the
library will need.

It's fun to take a week away from books...

(http://www.simonstl.com/projects/xlinkfilter/)



Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dante at mstirling.gsfc.nasa.gov  Thu Nov 12 16:17:16 1998
From: dante at mstirling.gsfc.nasa.gov (Dante Lee)
Date: Mon Jun  7 17:06:28 2004
Subject: Dante Lee
Message-ID: <Pine.LNX.3.95.981112120613.28481B-100000@mstirling.gsfc.nasa.gov>

Do you input the actual image tag into the xsl or the xml document, or is
it the HTML document??

______________________________________________________________

      d                    t                 l
      d                    t                 l
      d                ttttttttt             l
 dddddd   aaaa    nnnn     t      eee        l    eee    eee
d     d  a    a  n    n    t     e   e       l   e   e  e   e
d     d  aaaaaa  n    n    t     eeeee       l   eeeee  eeeee
d     d  a    a  n    n    t     e           l   e      e
ddddddd  a    a  n    n    t     eeeee       l   eeeee  eeeee

_______________________________________________________________

	          Dante M. Lee    Code 588
        	NASA/GSFC Greenbelt MD 20771
 	Voice = 301-521-1077   Bldg = 23  Rm = W415 
 	  Email = dante@mstirling.gsfc.nasa.gov
                  dante4@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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov 12 17:40:49 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:28 2004
Subject: using xml/xsl/dom together
Message-ID: <026101be0e61$f2eae710$0200a8c0@mdaxke.mediacity.com>

related to the "where are we" thread, i'm wondering if there
is enough in xml/xsl/dom to have a web page where a user can
click on their desired appearance, and the page re-arranges, suppresses
undesired content, and perhaps changes style?
all on the client side? (i mean in theory based on specs).

furthermore, could the xml have links inside, and based on the 
chosen style, the UA would decide to load and embed (or not)
the linked-to resources?

this capability roughly happens all the time on web sites 
(user "personalization"), but it isn't interactive on the page,
and requires a roundtrip to the server every time to go fetch
some pre-formatted html.

i've read the 3 specifications, but i'm still at a loss how
this (to me) relatively simple application could be built.

if there is an example somewhere that shows this, just point me
at it. i realize the real-world client-side implementations are quite
there yet (does ie5 have enough?), but i'm unclear even how
we are *supposed* to tie these things together, particularly
when my xml documents will typically be split into several
underlying files, none of which will have a specified style sheet.
and do i have to wait for action/behavior sheets before there
is an easy way to combine my scripting of the DOM with xsl?

thanks.

-mda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From laurie.mann at ansys.com  Thu Nov 12 17:58:20 1998
From: laurie.mann at ansys.com (Laurie Mann)
Date: Mon Jun  7 17:06:29 2004
Subject: using xml/xsl/dom together
Message-ID: <7D70697C0E38D111B4FF080036B39A038C72AC@ntdevexc.ansys.com>

> From:	Mark D. Anderson [SMTP:mda@discerning.com]
	>related to the "where are we" thread, i'm wondering if there
	>is enough in xml/xsl/dom to have a web page where a user can
	>click on their desired appearance, and the page re-arranges,
suppresses
	>undesired content, and perhaps changes style?
	>all on the client side? (i mean in theory based on specs).

	>furthermore, could the xml have links inside, and based on the 
	>chosen style, the UA would decide to load and embed (or not)
	>the linked-to resources?

	From a tech writer's standpoint, this would be really ideal.

	We're looking at moving to XML (we're currently in Interleaf),
	and have produced most of our documents in HTML as well
	as in hardcopy during the last release.  But it would be a GREAT
	thing to be able to, once the documents are properly tagged in
	XML, put all docs on a Web site and/CD-ROM, have the user
	speficy which products and platforms they are using, and have
	documents "create themselves."  I know there are some very
expensive
	XML-based products out there that will let the AUTHOR run
scripts
	to make docs on the fly, but, frankly, it would be even better
to
	have the capability to let the USER customize the final doc/Web
site
	for their own needs.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Thu Nov 12 18:00:04 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:29 2004
Subject: Images in XML
In-Reply-To: <Pine.LNX.3.95.981112120613.28481B-100000@mstirling.gsfc.nasa.gov>
References: <Pine.LNX.3.95.981112120613.28481B-100000@mstirling.gsfc.nasa.gov>
Message-ID: <13899.8432.580054.613626@localhost.localdomain>

Dante Lee writes:

 > Do you input the actual image tag into the xsl or the xml document,
 > or is it the HTML document??

Yes.

More seriously, how do you want to do it?  You could actually dump a
base64-encoded copy of the image right into the XML, you could
reference an image externally, or you could add the image using XSL.
With XPointer, you can even point to an IMG element in an HTML
document.

Of course, you'll need software that understands what you're doing,
but as far as XML is concerned all of the solutions are valid.


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


From db at Eng.Sun.COM  Thu Nov 12 18:05:36 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:29 2004
Subject: Back to XObjects was XLink - where a
References: <TFSHEECZ@dpsl.co.uk>> <364AAE1E.84704C93@eng.sun.com> <364AD6E0.E7B489A2@mecomnet.de>
Message-ID: <364B211B.A19A5EA4@eng.sun.com>

James -- I see you accept the point that the problem isn't that
simple.  However, there's also the implied one that different
folk need different answers.  The answers I would have given to
those questions are not the ones you gave.  Different assumptions
can lead to a need for different answers.  A base mechanism must
be a bit more flexible than that.

- Dave


james anderson wrote:
> 
> David Brownell wrote:
> >
> > Graham Moore wrote:
> > >
> > > Eliot wrote
> > >
> > > > The last two [java class for elements / swing classes] are no different
> > > > from requiring a style sheet--someone still has to provide
> > > > a per-document or document type definition of what the styling should
> > > > be
> > >
> > > The functional binding / class => element could be done as a default. Look
> > > in the location where the document was acquired from using the element name
> > > as the class name. It would just work, with no additional configuration
> > > files. If no class exists then the node is just a node.
> >
> > That doesn't seem sufficient to me.  What's the package name?
> 
> a mapping from the namespace name. (java packages may require an intermediate)

Assumes there's a namespace name.

> > What about classes that should represent multiple element types?
> 
> specialize the class appropriately

Assumes creating a class is zero cost, and doesn't accomodate open
ended sets of element types.

> > What about the different semantics associated with different namespaces?
> 
> that's what packages are for.

Assumes folk don't have common semantics in different namepaces.

> > Suppose you want the element and class names to be different, perhaps because
> > you and your users work with different natural languages?
> 
> support an architectural attribute, with appropriate defaults in the
> attribute definitions.

Assumes the folk defining the mappings are the ones defining the
attributes.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Thu Nov 12 18:32:19 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:29 2004
Subject: Back to XObjects was XLink - where a
References: <TFSIXERP@dpsl.co.uk>>
Message-ID: <364B26B1.8A6AC5B@eng.sun.com>

Graham Moore wrote:
> 
> > That doesn't seem sufficient to me.  ...
> 
> Its completely insufficient. But it is a base level ...

Right; many folk have reinvented that level!  Nobody, I think, denies
that the _model_ is accepted.  What I'm saying is that now that's been
agreed, it's time to provide a framework for answering questions such
as the ones I posed.

 
> The model I have working uses XML config files to specfiy the binding and
> allows the specification of more powerful delegation structures than simply
> inheriting from the w3c.node.

I've got an API driven approach, which could be driven based on config
files using an XML syntax like the one I suggested a while back.  But
the API can also be driven in other ways, too.  ("Element Factory", an
interface that can be implemented in many ways.  I'll post more later.)

Some delegation support is needed, I'd agree.  Everyone seems to focus
on subclassing though (implying a standard DOM implementation, not just
interface).  I suppose at some level these differ only slightly:

	MyXObject	foo = (MyXObject) node;
	MyXObject	bar = (MyXObject) node.getUserObject ();

The main differences I see are that (a) "bar" (delegation) costs more in
terms of memory, and (b) "bar" won't naturally have the entire DOM tree
as context, without establishing some bidirectional linking policy much
like the parent/child one that DOM exposed only partially.  Also, (c) there
is no real likelihood of eliminating large chunks of the DOM tree without
letting the XObjects ("XML Beans") replace implementations of DOM methods.

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 globalrobotics.com  Thu Nov 12 19:39:10 1998
From: xml at globalrobotics.com (warren)
Date: Mon Jun  7 17:06:30 2004
Subject: using xml/xsl/dom together
In-Reply-To: <026101be0e61$f2eae710$0200a8c0@mdaxke.mediacity.com>
Message-ID: <000c01be0e74$b82fd410$76bbbcc0@cybertron>

Hi,

[IMHO]...

 I am a technology consultant for an innovative web solutions company.
Currently we are defining a road
map to an extensible standards platform (xml java etc).

 You are correct in the functionality the user requires
and from examining the specs we believe that this is
definitely possible, however what is currently
lacking is a functional product... a browser(scriptable operating system)!

 We believe that we require something along the lines of... a WYSIWYG xsl
editor/displayer, retrieving xml data by xql. the editor [DOM] would then
parse & validate and via namespaces allow custom written java components to
render or compute the tag/elements.

 This allows developers to create full component based web applications,
page-masters to create full print quality & graphics & multimedia web
content, while at the same time allowing a user to customize their stock
quotes into an easily understandable presentation.

 But why wait for MS to implement this into IE5 etc.  Simply an application
to leverage these standards is all we want... let independent solution
developers do the rest..

 There are several other areas that we are investigating such as message
delivery and interprocess communication. if you are in the same boat as I
am, I would like to hear you opinions.

regards,

Warren.


-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
Mark D. Anderson
Sent: Friday, November 13, 1998 6:29 AM
To: xml-dev@ic.ac.uk
Subject: using xml/xsl/dom together


related to the "where are we" thread, i'm wondering if there
is enough in xml/xsl/dom to have a web page where a user can
click on their desired appearance, and the page re-arranges, suppresses
undesired content, and perhaps changes style?
all on the client side? (i mean in theory based on specs).

furthermore, could the xml have links inside, and based on the
chosen style, the UA would decide to load and embed (or not)
the linked-to resources?

this capability roughly happens all the time on web sites
(user "personalization"), but it isn't interactive on the page,
and requires a roundtrip to the server every time to go fetch
some pre-formatted html.

i've read the 3 specifications, but i'm still at a loss how
this (to me) relatively simple application could be built.

if there is an example somewhere that shows this, just point me
at it. i realize the real-world client-side implementations are quite
there yet (does ie5 have enough?), but i'm unclear even how
we are *supposed* to tie these things together, particularly
when my xml documents will typically be split into several
underlying files, none of which will have a specified style sheet.
and do i have to wait for action/behavior sheets before there
is an easy way to combine my scripting of the DOM with xsl?

thanks.

-mda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From arthur.rother at ovidius.com  Thu Nov 12 19:41:33 1998
From: arthur.rother at ovidius.com (Arthur Rother)
Date: Mon Jun  7 17:06:30 2004
Subject: Endtag attributes
In-Reply-To: <364A665A.EA3B428D@technologist.com>
References: <36474321.DE4EA5A3@toolsmiths.se>
 <wk67cna6cp.fsf@ifi.uio.no>
Message-ID: <3.0.6.32.19981112143944.007aa230@onepine.com>

Isn't there a much simpler solution, with which
you can avoid end tag attributes with just
one pass over the input document.

The way to go is maybe using dynamical generated entities.

When creating the output stream, generate a header like:

<!DOCTYPE whatever PUBLIC "whoever"
[
...
<!ENTITY % attrdecl SYSTEM "attrdecl.ent">
%attrdecl;
]>

Then, for each element needing an endtag attribute 'attr', do
for each starttag encountered

<elem attr="&elem_2_3_4_attr" ... >

Last thing, for each endtag encountered, corresponding to the
starttag found, do:
(pseudo c command)

writeto("attrdecl.ent","<!ENTITY elem_2_3_4_attr \"value\">\n");

where value is the value, you originally wanted to assign to the endtag
attribute.
The entity for the attribute name has to be unique ofcourse. This is
achieved by using some kind of a tumbler id in the entity name. One could
ofcourse also use a running counter.

In the next processor, the entities are resolved.


-arthur

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Suli.Ding at geis.ge.com  Thu Nov 12 19:59:10 1998
From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS))
Date: Mon Jun  7 17:06:30 2004
Subject: Doc2Xml
Message-ID: <F2A665AC0054D1119D0F00805FFECA120191530A@roc01bxgeisge>

Richard,

You are right. The version of the program you have can't do that. I have
updated the HTML page at
	http://www.geocities.com/SiliconValley/Platform/4871/
The zip files are updated also. You have to get a copy of the program to
make it work the way you want.

Best regards,

Suli


> ----------
> From: 	Sargeant, Richard (GEIS)
> Sent: 	Wednesday, November 11, 1998 9:24 AM
> To: 	Ding, Suli (GEIS)
> Subject: 	Doc2Xml
> 
> Hi Suli,
> 
>    I have been trying your Doc2Xml program and have a question. How do I
> create new tag pairs inside other tag pairs ?
> 
> For Example:
>    My input file is an Edifact document and the sender & receiver fields
> contain qualifiers...
> 
> 	
> UNB+UNOA:1+RICHARD:ZZ+SARGEANT:ZZ+971029:0847+REF00032++*ANY'UNH+1+ORDERS.
> ..etc
> 
>    If I run  this via your example table the results looks like...
> 
> 		<?xml version="1.0"?>
> 		<UNB Version="1" Date="971029" Time="0847">
> 			<SenderId>RICHARD</SenderId>
> 			<SenderQual>ZZ</SenderQual>
> 			<ReceiverId>SARGEANT</ReceiverId>
> 			<ReceiverQual>ZZ</ReceiverQual>
> 			<IntCtlRef>REF00032</IntCtlRef>
> 			<Pswd></Pswd>
> 			<AppRef>*ANY</AppRef>
> 			<UNH MsgRef="1" MsgType="ORDERS"
> 
>    However, what I would like to output is...
> 
> 		<?xml version="1.0"?>
> 		<UNB Version="1" Date="971029" Time="0847">
> 			<Sender>
> 				<SenderId>RICHARD</SenderId>
> 				<SenderQual>ZZ</SenderQual>
> 			</Sender>
> 			<Receiver>
> 				<ReceiverId>SARGEANT</ReceiverId>
> 				<ReceiverQual>ZZ</ReceiverQual>
> 			</Receiver>
> 			<IntCtlRef>REF00032</IntCtlRef>
> 			<Pswd></Pswd>
> 			<AppRef>*ANY</AppRef>
> 			<UNH MsgRef="1" MsgType="ORDERS"
> 
>    I have tried various combinations without success. Is this possible ?
> 
> regards
>    Richard Sargeant
> 
> e GE Information Services__________________
> Prof.E.M.Meijerslaan 1		
> 1183 AV Amstelveen
> Netherlands
> 
> Tel: 	+31 20 503 5576	Dialcomm: 381 5576
> Fax:	+31 20 640 3825	Dialcomm: 550 3825
> Mobile:	+31 653 930239
> internal web site: http://luggage.is.ge.com 
> __________________________________________
> 
> 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Thu Nov 12 20:02:19 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:30 2004
Subject: Open-source licensing (was: XLink library)
References: <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca> <199811111622.LAA12163@hesketh.com>
Message-ID: <364B3EC6.2CCEACA5@locke.ccil.org>

Simon St.Laurent wrote:

> The library is and will be open source, though at this point I haven't
> firmly decided on a license. (GPL is likely, in some slightly modified
> form.)

I suggest that you avoid the GPL for components, as GPLed components
can only be used to build GPLed applications.  Alternatives are:

	the LGPL at http://www.gnu.ai.mit.edu/copyleft/lgpl.html;
	the MPL at http://www.mozilla.org/NPL/MPL-1.0.html;
	the BSD license (aka "James Clark" license)
		at http://www.opensource.org/bsd-license.html
	the public domain.

I favor the last two options for large and small components
respectively.

For information and texts, see http://www.opensource.org .

Also note that modified versions of the GPL are *forbidden* by its
own copyright notice: the GPL is not itself under the GPL, but
under a license that says "anyone may copy, but changes are forbidden."
That is to prevent the proliferation of minutely different versions
of the GPL.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Thu Nov 12 20:06:34 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:30 2004
Subject: ID attribute defaults
References: <3.0.32.19981111091752.00b4fdf0@pop.intergate.bc.ca> <3.0.5.32.19981111204941.009bc9d0@amati.techno.com>
Message-ID: <364B3FD6.42DFE866@locke.ccil.org>

W. Eliot Kimber wrote:

> It's my personal feeling that the inability to provide defaults for ID,
> IDREF(S), and ENTITY(IES) attributes is a bug (in SGML unavoidably
> inherited by XML).

There is no evidence for the presence of such a constraint in XML;
the relevant clause (3.3.2) is silent.  Clause 3.3.1 does require
that ID attributes have a default of either #IMPLIED or #REQUIRED,
but no restrictions are placed on IDREF, IDREFS, ENTITY, or ENTITIES,
so they may have default values in XML.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Thu Nov 12 20:16:55 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:30 2004
Subject: Open-source licensing (was: XLink library)
Message-ID: <3.0.32.19981112121149.0205ac80@pop.intergate.bc.ca>

At 03:02 PM 11/12/98 -0500, John Cowan wrote:
>I suggest that you avoid the GPL for components, as GPLed components
>can only be used to build GPLed applications.  Alternatives are:
...
>	the MPL at http://www.mozilla.org/NPL/MPL-1.0.html;
...

The Mozilla guys put an *immense* amount of work into this, and
got input from all the open source icons (Linus, Larry, Eric, etc).
James seems happy with it too.  -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov 12 20:16:55 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:30 2004
Subject: Full Disclosure: What The XML Processor Must Tell The XML 
	 Application
References: <3641FCE4.61D46D15@locke.ccil.org> <364A6634.4E060F06@technologist.com>
Message-ID: <364B429F.2BA10592@locke.ccil.org>

Paul Prescod scripsit:

> I think David agrees with me that XML processors do not have enough
> information to make the decision about whether entity references should be
> expanded or not.

What about an XML processor that (as a part of its design) never expands
external entity references?

For example, one might want to have an ultrafast XML processor that
works only from a string input source and can therefore operate
in embedded environments.  It cannot have a SAX interface as SAX
is currently defined without violating XML 1.0.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From mda at discerning.com  Thu Nov 12 20:44:28 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:30 2004
Subject: using xml/xsl/dom together
Message-ID: <035f01be0e7c$099229a0$0200a8c0@mdaxke.mediacity.com>

> But why wait for MS to implement this into IE5 etc.  Simply an application
>to leverage these standards is all we want... let independent solution
>developers do the rest..

I don't want to wait, i want to start programming towards what is
going to be available on the client. By "client", i mean one that
will have implemented the emergent standards, whether it be IE,
mozilla, or opera.

I'm *not* interested in something requiring some other ISV's technology
on the client-side. There may be some space for the numerous
"intranet-in-a-box" startups that stick java or activeX in the browser
to compensate for lacking standards or standards-compliance.
But i want my architecture to have broad reach, and that means
that on the client i only want to rely on the capabilities
implicit in a fully standard-compliant browser, whenever that happens.

My problem is that i can't see how that it is even *supposed* to work,
even if there were a standards-compliant browser. The conceptual
model in the xsl/xml specs seems to be that there is one xml document and
it specifies a style sheet embedded in it. That is pretty far off
from what i have in mind. similarly, i don't quite see how
xsl/dom/action-or-behavior-sheets all come together.

-mda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Thu Nov 12 21:22:06 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:30 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are
	  we?)
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
	 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca> <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
Message-ID: <364B51E5.E83031DC@locke.ccil.org>

W. Eliot Kimber scripsit:

> [D]ata
> entities is the only feature of SGML not provided by XML that also has
> significant *semantic* utility (as opposed to being a syntactic convenience
> like markup minimization or the LINK feature) [...]

And can you enlighten those of us who don't know SGML about
the semantics of data entities?  Thanks.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From b.laforge at jxml.com  Thu Nov 12 21:44:49 1998
From: b.laforge at jxml.com (Bill la Forge)
Date: Mon Jun  7 17:06:31 2004
Subject: Back to XObjects was XLink - where a
Message-ID: <002d01be0e86$0fb550a0$ab026982@thing1.camb.opengroup.org>

David and all,

> MyXObject foo = (MyXObject) node;
> MyXObject bar = (MyXObject) node.getUserObject ();


Wrapping a user object with a DOM element is a liberating concept,
especially as it lets you use things like Swing components for the base
class, the DOM tree becoming, in effect, a bean box.

There are then two alternatives:

1. Exposing the wrapper element to the user object. Handy for some 
things where the user object needs to navigate the DOM tree, but quite
restrictive then on the choice of possible user objects.

2. Providing the data and other user object interconnections. This is where
meta data has its real strength--there is simply too much code to write with
an api.

Paul Rabin and I have been working on an expansion of the bindings document
to encompass the meta data needed to provide both the data mapping and
support arbitrary connections (add/North, addTag/"View", addListener/java.awt.ActionListener,
etc.).

One of the nice things to fall out is BindingSets. A BindingSet object supports the
DomBuilder interface, but has an associated set of Bindings documents to support
various types of documents. There is closure, so that all the Bindings of a set belong
only to that one set. (With a minor exception for subsets.)

The "big deal" about binding sets is that it is that you can now determine which set
of bindings to use when one document references another--by default, you just look
at the bindings that were used with the current document and go with the associated
bindings set.

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


From Denis_Haskin at iacnet.com  Thu Nov 12 22:06:01 1998
From: Denis_Haskin at iacnet.com (Denis_Haskin@iacnet.com)
Date: Mon Jun  7 17:06:31 2004
Subject: XSchema/DCD to DTD?
Message-ID: <852566BA.0078A5E6.00@circus.med.iacnet.com>

(I was sorely tempted to cross-post to XSL-List, but given that I (hope)
XML-Dev is a superset of XSL-List, I will refrain for the time being...)

I could have sworn I saw a recent post about an XSchema-to-DTD converter,
but I am unable to find any mention of such a thing in either the XML-Dev
or XSL-List archives.

Ideally, what I am really looking for is an XSL stylesheet to transform a
DCD into a DTD, and XSchema (the latter is optional).  I can put one
together myself, but I suspect I'm not the first person to want to do this.

(Why?  Well, I would prefer to keep my document in definition in DCD
(XSchema would be okay, too, but I just happened to start with DCD first)
but it needs to be consumed by people who are more comfortable with DTDs.)

Thanks for any pointers,

dwh



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Denis_Haskin at iacnet.com  Thu Nov 12 22:23:17 1998
From: Denis_Haskin at iacnet.com (Denis_Haskin@iacnet.com)
Date: Mon Jun  7 17:06:31 2004
Subject: XSchema/DCD to DTD?
Message-ID: <852566BA.007A3E6E.00@circus.med.iacnet.com>

Ignore my recent question ("an XSL stylesheet to transform XSchema/DCD to
DTD").  Re-reading things a bit closer in the XSL spec, it's not clear to
me it can be done with XSL.  -sigh-

Thanks,

dwh



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tyler at infinet.com  Thu Nov 12 22:34:38 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:31 2004
Subject: Oracle XML
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org> <364AB030.EFAC2ADE@sophia.inria.fr>
Message-ID: <364B6296.3598F440@infinet.com>

"Philippe Le H?garet" wrote:

> K. Travis Walsh wrote:
> >
> > Oracle officially anounced today it's XML strategy.
> >
> > For those of you who didn't know there is a java parser built into this
> > new release of Oracle 8i.
>
>   Like netscape, They can't write well-formed XML document.
>
>   <?xml version="1.0"> is not a well-formed XML document.
>

Hey give them a break.  Forgetting that little question mark is something
everyone has done from time to time when handcrafting XML documents.  I know,
cause I have done this many times.  If XML did not inherit SGML's syntax, I bet
we would all of a much cleaner syntax to work with with less user errors as a
result.

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


From ralph at fsc.fujitsu.com  Thu Nov 12 22:47:51 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:31 2004
Subject: Defining Behavior Was: Back to XObjects was XLink
In-Reply-To: <00c201be0e21$af6209a0$1b11e391@mhklaptop.bra01.icl.co.uk>
Message-ID: <3.0.5.32.19981113054340.009f7b80@pophost.fsc.fujitsu.com>

At 09:49 AM 11/12/98 -0000, Mike Kay wrote:
>
>And this reflects a lingering concern I have about XLink,
>which is that it is putting display-time behaviour into the
>XML document rather than into the stylesheet. I'm not
>convinced that XLink is defining relationships at a high
>enough level of abstraction, and I'd prefer to see work on
>interactive behaviour happen in the XSL world.

A long standing issue, still under discussion. In HyBrick, behavior depends
on a *combination* of DTD and stylesheet information. This follows from the
use of DSSSL-online, which defines "make link" and "make external graphic"
procedures. 

In the original demo version of HyBrick (which was not publically
distributed) the "make link" procedure was used to create the equivalent of
HTML A-type elements. In the current release, it has been adapted for the
locators in xml:link-type elements, except that the HTTP sub-system isn't
currently enabled for link-type elements, so links only work with the local
file system. The "make external graphic" procedure was (and is) used to
create the equivalent of HTML IMG-type elements. 

The element types themselves of course have to be declared in the DTD, and
their attributes assigned the proper declared values. Note that the "make
link" and "make external graphic" procedures also require that the
attribute values be declared. Of course, the attribute declared values in
the DTD and stylesheet *should* match. The several people I've talked to
about this have all stated that enforcing this match is an "application"
level issue.

Another factor to be aware of though is that the "document groups" defined
in the current XLink draft affect link "visibility" - which can have a
subtle - and confusing - influence on behavior. I would call this another
aspect to the "high enough level of abstraction" that you referred to.
Current HTML users are used to a "go to" model of linking. Hypertext
experts have always known that we can do better. The issue is, pre-Web
hypertext systems where built, whatever the ultimate aspirations of their
designers, as *closed* systems. Even in a closed system, applying even
what's currently defined in the XLink/XPointer specs can get interesting.
Applying these concepts to the open environment of the Web is going to get
even more interesting. That's why it's important for more people to start
experimenting with HyBrick, so they can get more insight into these issues
first hand.

>
>In particular, I am really uncomfortable with the one-to-one
>mapping of stored XML documents to "units of display". I
>think the presentation facilities (stylesheets and hyperlink
>browsing) should be independent of the granularity of
>storage.

>
>To put things another way, if I'm going to have to
>pre-process my corpus by splitting it into lots of linked
>page-sized chunks to make it browsable, I might as well
>render those chunks in HTML while I'm about it.

Agreed. In particular, with XPointer you should be able to retrieve
"fragments" rather than having to retrieve entire documents. This day will
come.


Best regards,

Ralph E. Ferris
Fujitsu Software Corporation





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From WalterS at ile.com  Fri Nov 13 00:27:39 1998
From: WalterS at ile.com (Walter Smith)
Date: Mon Jun  7 17:06:31 2004
Subject: XML and Internationalization...
Message-ID: <19B8452E57A0D111B04100805F6F312C0198BC73@email.ile.com>

> -----Original Message-----
> From: Deke Smith [mailto:deke@tallent.com]
> Sent: Monday, November 09, 1998 11:45 AM
> To: xml-dev@ic.ac.uk
> Subject: Re: XML and Internationalization...
> 
><snip/>
> 
> Here's my question: 
> 
> As I understand it, TMX is a format for translation 
> "dictionaries" -- or lists of equivalent words, phrases, 
> sentences or paragraphs in different languages. TMX also 
> allows the preservation of formating within phrases, such as 
> boldface, italic, etc.
> 
> I always judge tools by what *I* need from them and that is 
> what I need from TMX. Is it meant to do more than what I have 
> asked it to do? Is this "dictionary" concept something TMX is 
> *meant* for?
> 
> I am under the impression that TMX can also have embedded 
> "macros" within phrases. By "macro", I mean processing 
> commands that may be understood only by a specific scripting 
> language. Am I right?

We served as technical chair of the group of localization companies that
participated in the creation of the TMX format. As Tony said in an earlier
email, it was conceived as a Translation Memory Exchange format. In the
translation/localization biz, we use these translation memory tools (really
nothing more than bi-text databases) to capture prior translation effort and
reuse it where ever applicable. Most of the data/file types that
localization companies traditionally encounter is _not_ native SGML/XML. As
such, vendors are left to their own devices to decide how to process the
plethora of proprietary formats (resource files, DTP files, etc.) to
efficiently access the embedded translatable text. Needless to say, everyone
has come up with very different ways of doing this. The TMX format simply
seeks to provide a pragmatic way of exchanging TM data among disparate
environments, and really nothing more.

Another translation-related tag set is the OpenTag format
(http://www.opentag.org), which we launched over a year ago and have been
collaborating on with others in the localization industry. It specifically
seeks to provide a common method to markup textual data that is extracted
from functional/presentational/structural markup for the purposes of
language translation or any sort of NLP activity. The OpenTag schema was
specifically designed to abstract source differences at the element level,
while disambiguating context issues at the attribute level. Again, the data
types we're mainly dealing with is primarily everything but MLs. It's
flexible enough just about any data you can parse and extract from your
source environment, and there's even elements and attributes that be
employed to induce additional information into the data. While it wasn't
originally conceived to be a tag set for data creation, you may find the
flexibility you're looking for. You would then get the added bonus that your
data would already be ready for processing by any OpenTag-aware translation
tools and environments.

Cheers,
Walter
----------------------------------------------
Walter L. Smith (walters@ile.com)
Emerging Technology Analyst
International Language Engineering Corporation
5700 Flatiron Parkway
Boulder, CO 80301
303-245-7584 (vox)
303-596-7343 (cel)
303-245-7973 (fax)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Fri Nov 13 05:50:19 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:31 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are
   we?)
In-Reply-To: <364B51E5.E83031DC@locke.ccil.org>
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
Message-ID: <3.0.5.32.19981112234611.0098ecd0@amati.techno.com>

At 04:23 PM 11/12/98 -0500, John Cowan wrote:
>W. Eliot Kimber scripsit:
>
>> [D]ata
>> entities is the only feature of SGML not provided by XML that also has
>> significant *semantic* utility (as opposed to being a syntactic convenience
>> like markup minimization or the LINK feature) [...]
>
>And can you enlighten those of us who don't know SGML about
>the semantics of data entities?  Thanks.

Sure.

SGML and XML both have the concept of data content notations, declared with
the NOTATION declaration:

<!NOTATION MyDataType PUBLIC "http://www.drmacro.com/mydatatype.xml" >

Notations allow you to give names to specific data types, that is, the
rules that govern the interpretation and processing of a particular type of
data. XML is an example of a data content notation, GIF is another.  For
example, to refer to another XML document as a data entity, I would do this:

<!NOTATION xml PUBLIC "http://www.w3.org/rest of URL for XML spec" >
<!ENTITY somedoc SYSTEM "somedoc.xml" NDATA XML >

This entity "somedoc" is an unparsed entity in XML terms, meaning that it
is not parsed in the context of the document that references it (even
though it will of course be parsed as an independent document should it
ever be processed).

In SGML, you can define attributes for notations just as you can for
element types ("data attributes"). These attributes act as parameters to
the processors that know how to interpret data governed by the notations.
In SGML, you can specify data attributes either as part of a data entity
("unparsed entity") declaration or on an element that is also governed by a
notation.  With the WebSGML TC to SGML, you can also use data attributes as
part of the declaration of attributes in order to define specific data
types for attributes.

One use of data attributes is to associate attributes with data entities.
The textbook use is parameters associated with graphic data entities, e.g.:

<!NOTATION gif SYSTEM >
<!ATTLIST #NOTATION gif
   width 
     CDATA
     "100"
   height
     CDATA
     "100"
>

<!ENTITY big-graphic SYSTEM "picture.gif" NDATA gif
  [ width="640" height="480"] 
>

A typical SGML processor will, when it encounters a reference to the entity
big-graphic, will see if it knows of a processor that can process the
notation "gif". It finds one and passes it the information from the entity
declaration, including the data attributes, which the processor presumably
takes as parameters.  The presumption is that the notation has defined, as
part of its formal documentation or definition, what the attributes should
be.  I.e., somewhere in the definition of this fictional gif notation (or
the local processor associated with the gif notation), the documentation
says something like "processors should accept height and width parameters
from which they determine the presentation size of the graphic".

Data attributes can be used with elements that are "governed" by a
notation.  For example, say I want to define a query notation that I'll use
to address things in some repository.  I first define a notation that
represents the general query mechanism:

<!NOTATION MyQuery PUBLIC "http://www.drmacro.com/notations/myquery.xml" >

The resource identified by the external identifier should be the
authoritative definition of what the notation is about, how to process it,
etc.  *IT SHOULD NOT BE A PROGRAM*.  Programs should be associated with
notations by mapping their external identifiers to programs, dlls,
tool-provided functions, etc., through some tool-specific mechanism. For
example, in PHyLIS, my HyTime engine, my intent is to provide a
configuration file that lets you map notations to dynamic libraries or
objects (e.g., COM objects, Java classes, Corba whatsits, etc.).

To make the query easy for authors to specify, I want to provide a few
parameters that authors fill in to specify the query details. I do this by
declaring some notation attributes to serve as the parameters to the query:

<!ATTLIST #NOTATION MyQuery
   table       -- Name of table query is applied to --
     CDATA
     #REQUIRED 
   select-on   -- Value to select on --
     CDATA
     #REQUIRED
   where       -- Field whose value to select on --
     (name | ssnum | phone)  -- Some field names --
     #REQUIRED
>

I then declare an element type that can be used to specify queries in
documents:

<!ELEMENT SelectData -- Do a query --
  - O
  EMPTY
>
<!ATTLIST SelectData
   notation
     NOTATION
     (MyQuery)
     MyQuery
   table       -- Name of table query is applied to --
     CDATA
     #REQUIRED 
   select-on   -- Value to select on --
     CDATA
     #REQUIRED
   where       -- Field whose value to select on --
     (name | ssnum | phone)  -- Some field names --
     #REQUIRED
>

Note the NOTATION attribute. This attribute defines the SelectData element
as being "governed by" the notation MyQuery.  This means that *after* the
document is parsed, the processor will process this element type by looking
up a processor associated with the notation
"http://www.drmacro.com/notations/myquery.xml" (remembering that the
external ID is the real name, the local name, MyQuery, is just a local
proxy).  It finds one, so it passes the whole SelectData element to it
(that is, the element node constructed from the SelectData markup).  The
element's attributes are associated with the notation attributes simply by
matching the names [the Data Attributes for Elements (DAFE) facility of the
HyTime architecture provides machinery for resolving name conflicts, but
you wouldn't normally need this extra stuff because you can just define
your elements and notations so as to avoid the problem.]

The processor knows to expect to find the three attributes declared for the
notation (because the notation serves the processor and thus reflects what
it's defined as needing). It uses normal element processing (e.g.,
element.Attributes["table"]) to get the value of the attributes, does what
it does, and returns the result. The processor takes the result and goes on
doing whatever it's doing.

One way to think about data attributes is that they provide the binding
between software components in the outside world and data objects in the
document, either data entities or elements. Essentially, the processor for
some data type defines its interface, in the API sense, and the notation
attributes "implement" that interface by providing the necessary attributes.  

Of course, it's up to particular processing systems to provide the actual
integration APIs and configuration infrastructure so that processors and
documents can take advantage of notations and data attributes, but it's
pretty basic stuff.

I think that data attributes, especially when used with elements governed
by notations, are really really valuable. I pushed very hard for their
inclusion in XML but was unable to convince the rest of the WG. I hope that
the XML developers will reconsider data attributes when XML is eventually
revised.  I think they're very valuable.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Fri Nov 13 10:18:08 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:31 2004
Subject: SAX Future (was Re: Oracle XML)
Message-ID: <004001be0eee$466ce6e0$7008e391@bra01wmhkay.bra01.icl.co.uk>


-----Original Message-----
From: david@megginson.com <david@megginson.com>
To: XML Developers' List <xml-dev@ic.ac.uk>
Date: 12 November 1998 15:35
Subject: SAX Future (was Re: Oracle XML)


>Richard Anderson writes:
>
> > For interest, have there been any developments of a 'lower level'
> > SAX to expose DTD info too ?
>
>We've talked about it -- I need to be convinced that there is a big
>enough demand for that (it would be useful only for very specialised
>applications).  I think that the following for SAX 1.0 are probably
>higher priorities:
>
My view:

- I think it is time to start talking about SAX 2.0
- I think David's list of requirements captures the main points
- I think we should get DTD info in while we're about it, though it can be
an optional feature
- I'd add two more features: (a) an option to ask the parser not to break
character data except at element boundaries. This is because it's so easy
currently to write applications that are wrong because they rely on a parser
behaviour that the SAX interface doesn't guarantee. (b) a "parser manager"
to provide control of which parser is used. (This of course is a bit of
software not just an interface! - I'll offer the parser manager in SAXON as
a starter; it should be extended to allow a pile of parser filters to be
configured)

I think we can manage compatibility as follows:
- We design 2.0 so that an application that conforms to SAX 1.0 also
conforms to SAX 2.0
- A standard wrapper round a SAX 1.0 parser should enable it to conform to
SAX 2.0, providing null/default implementations of the new features where
necessary. (E.g. the response to the question "are you a validating parser?"
is "maybe").

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From daveh at persimmon.co.uk  Fri Nov 13 10:26:17 1998
From: daveh at persimmon.co.uk (Dave Halls)
Date: Mon Jun  7 17:06:31 2004
Subject: using xml/xsl/dom together
References: <026101be0e61$f2eae710$0200a8c0@mdaxke.mediacity.com>
Message-ID: <364C0931.556A30EB@persimmon.co.uk>

Mark D. Anderson wrote:

> related to the "where are we" thread, i'm wondering if there
> is enough in xml/xsl/dom to have a web page where a user can
> click on their desired appearance, and the page re-arranges, suppresses
> undesired content, and perhaps changes style?
> all on the client side? (i mean in theory based on specs).
>
> furthermore, could the xml have links inside, and based on the
> chosen style, the UA would decide to load and embed (or not)
> the linked-to resources?
>
> this capability roughly happens all the time on web sites
> (user "personalization"), but it isn't interactive on the page,
> and requires a roundtrip to the server every time to go fetch
> some pre-formatted html.

We put a demo up a year ago that does this on the client side using
XMLJ, our Standard ML-based XML processing library.
This runs on the JVM in the browser. Uses SAX or DOM-built trees.

See

http://research.persimmon.co.uk/mlj/demos/stylesheets/index.html

and

http://research.persimmon.co.uk/mlj/demos/stylesheets/about.html

for some blurb. Requires Netscape 4 or MSIE 4 (not Mac).

I've recently ported the combinator parser to Java for the
non-functional programmers. When I get shot of the short-term
things I'm doing (I can't believe it's a year since I did the demo),
I'll put something up to read/download. We've switched now
to server-side XML processing, I find it more interesting (my
opinion only of course) and there's loads to do. Also no hassle
with browsers, they really are the most shoddy pieces of software
ever written.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 13 12:01:54 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:31 2004
Subject: SAX Future
In-Reply-To: <004001be0eee$466ce6e0$7008e391@bra01wmhkay.bra01.icl.co.uk>
References: <004001be0eee$466ce6e0$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <13900.7613.719789.40250@localhost.localdomain>

Michael Kay writes:

 > - I'd add two more features: (a) an option to ask the parser not to
 > break character data except at element boundaries.

This is much easier to handle with a SAX filter that implements both
Parser and DocumentHandler and buffers the character data.  As a
matter of fact, I'd like to formalise the idea of a SAX filter in SAX
1.0.1 (I think I'd like the first two digits to correspond to the XML
version).

In fact, a string of filters (Chain of Responsibility in
Design-Pattern-speak) can give users an awful lot of control for very
little work.  Other interesting filters would automatically include
XML documents embedded with XLink into the parent document's event
stream, resolve namespaces (John Cowan has already done this),
normalise whitespace using xml:space, selectively filter out elements,
etc.  All of this can be done above the parser/driver level, so
there's no need to complicate SAX by including it in the core spec
itself (except for including a canonical Filter interface).

 > (b) a "parser manager" to provide control of which parser is
 > used. (This of course is a bit of software not just an interface! -
 > I'll offer the parser manager in SAXON as a starter; it should be
 > extended to allow a pile of parser filters to be configured)

Agreed, though the design may have to vary dramatically from language
to language.

 > I think we can manage compatibility as follows:
 > - We design 2.0 so that an application that conforms to SAX 1.0 also
 > conforms to SAX 2.0
 > - A standard wrapper round a SAX 1.0 parser should enable it to conform to
 > SAX 2.0, providing null/default implementations of the new features where
 > necessary. (E.g. the response to the question "are you a validating parser?"
 > is "maybe").

Yes, but how do we accomplish this?  Do we invent a new package name
for SAX 1.0.1 to avoid collision?


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


From j.j.wester at kpn-telecom.nl  Fri Nov 13 13:33:45 1998
From: j.j.wester at kpn-telecom.nl (Wester, JJ (ICT))
Date: Mon Jun  7 17:06:32 2004
Subject: Creation of XML documents
Message-ID: <199811131331.OAA19472@sat-relay2.pc.telecom.ptt.nl>

I am involved in a similar project: we want to  replace the current
inter-application communication techniques (RPC's, batch files etc) by XML
document exchanges. This because XML makes the interfaces more flexible.
We need methods and tools for the programmers who have to adapt old
applications, or build new applications that communicate through XML to
other applications.
The problem is that these programmers are used to RPC's etc. If they have to
use DOM, that would probably mean a lot of education and a lot of changes in
current applications. Also a lot of programs are written in COBOL, which
makes it more difficult to use DOM  I think.

The question is: what methods and tools can you offer these programmers?
What is feasible?
DOM? Which implies that the programmer constructs and sends an XML document
instead of calling a remote procedure.
DCE IDL? The programmer uses RPC's (as he does now), which are translated by
underlying middleware to XML documents?
But is this a practical solution?
What about using UML for your data definitions and then create stubs?

Any ideas?

----------------------------------------------------------------------------
--------------------------------
Johan Wester				Tel.  +31 50 585 16 01
KPN Telecom				Fax. +31 50 585 22 40
P.O. Box 958				j.j.wester@kpn-telecom.nl
9700 AZ  Groningen


> -----Original Message-----
> From:	Kurt Helenelund [SMTP:kurt@simberg.com]
> Sent:	donderdag 5 november 1998 14:03
> To:	xml-dev@ic.ac.uk
> Subject:	Creation of XML documents
> 
> I am working on a project where we will use XML to exchange information
> between
> applications in different government agenices. We want to implement both
> on-line access
> between applications and asynchronous store & forward type of
> mechanisms.
> 
> I understand that there are 'lots' of good XML parsers (we have tried
> some) out there and that SAX and DOM are
> the prefered ways for applications to 'read' XML structures. I would
> like to ask if there's anyone
> that have the opposite problem i.e. for applications to create XML
> documents on-the-fly. Of course
> the developer could 'hand code' the XML structures which is error prone
> and booring . I am looking
> for something (API, lib) so that we could avoid this.
> 
> I would like to have a 'library' to which the application developer
> could say 'using this DTD please
> instantiate a XML document and help me to fill it in'.
> 
> Any solutions?
> 
> 
> --
> _______________________________________________________________________
> Kurt Helenelund                                Mobile: +358 50 555 0192
> Simberg & Partners                             Home:   +358 9  294 0313
> Mielikintie 7B                                 Fax:    +358 9  294 0314
> FIN-04230 KERAVA, Finland                      Email:  kurt@simberg.com
> 
> 
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Fri Nov 13 14:27:02 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:32 2004
Subject: Stylesheets considered limiting (was Re: XLink - where are
    we?)
In-Reply-To: <3.0.5.32.19981112234611.0098ecd0@amati.techno.com>
References: <364B51E5.E83031DC@locke.ccil.org>
 <3.0.5.32.19981111210459.009ba510@amati.techno.com>
 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
Message-ID: <3.0.5.32.19981113082146.009bd5e0@amati.techno.com>

At 11:46 PM 11/12/98 -0600, W. Eliot Kimber wrote:
>At 04:23 PM 11/12/98 -0500, John Cowan wrote:
>>W. Eliot Kimber scripsit:
>>
>>> [D]ata
>>> entities is the only feature of SGML not provided by XML that also has
>>> significant *semantic* utility (as opposed to being a syntactic
convenience
>>> like markup minimization or the LINK feature) [...]
>>
>>And can you enlighten those of us who don't know SGML about
>>the semantics of data entities?  Thanks.

I meant to write "data attributes is the only feature of SGML..." and
didn't notice the mistake even when the question above was asked. I
answered the question I thought was being asked (that is, the question that
would have been asked had I not mistyped).  Of course, XML has data
entities, it just calls them "unparsed entities".  In SGML, data entities
may have data attributes, in XML they may not.

My appologies for any confusion this may have caused.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From RJA at arpsolutions.demon.co.uk  Fri Nov 13 15:02:00 1998
From: RJA at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:32 2004
Subject: Creation of XML documents
Message-ID: <000601be0f16$a5fbeac0$c5010180@p197>

> I would like to have a 'library' to which the application developer
> could say 'using this DTD please
> instantiate a XML document and help me to fill it in'.

I've got a C++ toolkit that is under development that sort of mets these
requirements. It has a SAX+DOM interface.   ( The COM variant will follow
very shortly for use in VB etc )

Using the SAX interface you can build a 'template' DOM and then fill in the
missing bits.

The toolkit has *no* dependancies on MSIE etc.

Heres some sample code for creating an XML EMAIL:

************ CODE SECTION START ****************

pDoc = pDOMAPI->createDocument();
 pRootElement = pDoc->createElement( L"EMAIL" );
pFrom = pDoc->createElement( L"From" );
 pRootElement->appendChild( pFrom );
pFrom->setAttribute( L"Priority", L"High" );
 pFrom->setAttribute( L"DeliveryReceipt", L"Yes" );
 pFrom->setAttribute( L"ReturnReceipt", L"Yes" );

pText = pDoc->createTextNode( L"RJA@arpsolutions.demon.co.uk" );
pFrom->appendChild( pText );

pTo = pDoc->createElement( L"To" );
pRootElement->appendChild( pTo );
pText = pDoc->createTextNode( L"enquires@arpsolutions.demon.co.uk" );
pTo->appendChild( pText );

pSubject = pDoc->createElement( L"Subject" );
pRootElement->appendChild( pSubject );
pText = pDoc->createTextNode( L"XML/DOM/SAX C++ Toolkit" );
pSubject->appendChild( pText );

pComment = pDoc->createComment(L"Main body of Email follows");
pRootElement->appendChild( pComment );
pBody = pDoc->createElement( L"Body" );
pRootElement->appendChild( pBody );

pText = pDoc->createTextNode( L"Seems OK so far." );
pBody->appendChild( pText );

pText = pDoc->createTextNode( L"I'll have to try harder to break it." );
pBody->appendChild( pText );

pPI = pDoc->createProcessingInstruction(L"PI",
                                          L"That's all folks!" );

pCC = pDoc->createElement( L"CC" );
pText = pDoc->createTextNode( L"xml_toolkit@arpsolutions.demon.co.uk" );
pCC->insertBefore( pText, NULL );
pRootElement->insertBefore( pCC,pTo );

CStdioWideStream stream;
pDOMAPI->writeXML( pRootElement, &stream );

*********** CODE SECTION END ***************

If your interested I can send you the C++ alpha toolkit.

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Fri Nov 13 16:17:26 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:32 2004
Subject: SAX Future
References: <004001be0eee$466ce6e0$7008e391@bra01wmhkay.bra01.icl.co.uk> <13900.7613.719789.40250@localhost.localdomain>
Message-ID: <364C5BCD.7D16DD34@locke.ccil.org>

david@megginson.com wrote:

> This is much easier to handle with a SAX filter that implements both
> Parser and DocumentHandler and buffers the character data.

Which someone using my ParserFilter class can write in < 1 day.

> In fact, a string of filters (Chain of Responsibility in
> Design-Pattern-speak) can give users an awful lot of control for very
> little work.

You betcha.  And because each filter component can specified by a Java
system property, chaining can be done at run time very neatly.

The highest level filter is specified as org.xml.sax.parser, and
each lower level is specified by <successor class name>.parser, thus:

	-D org.xml.sax.parser=com.domain.chance
	-D com.domain.chance.parser=com.domain.evers
	-D com.domain.evers.parser=com.domain.tinker
	-D com.domain.tinker.parser=com.domain.SAXDriver

sets up a chain where SAXDriver (the real parser) passes
to tinker, which passes to evers, which passes to chance, :-) which
passes to the application.

Of course all this can be set up programmatically too.

> All of this can be done above the parser/driver level, so
> there's no need to complicate SAX by including it in the core spec
> itself (except for including a canonical Filter interface).

Absolutely.
 
> Yes, but how do we accomplish this?  Do we invent a new package name
> for SAX 1.0.1 to avoid collision?

I think that would be better than new class names.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Fri Nov 13 16:19:22 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:32 2004
Subject: Walking the DOM (was: XML APIs)
References: <c=US%a=_%p=Cromwell_Media%l=ODIN-981113123456Z-22042@odin.cromwellmedia.co.uk>
Message-ID: <364C5C6F.971FD06B@locke.ccil.org>

Miles Sabin wrote:

> OK, I agree that this check is O(1). However, that's only
> because the granularity of the check is so coarse: a single
> document-level timestamp will cause a lot of unnecessary
> invalidation ...

Agreed.  But this isn't so important if there are few active
iterators (= iterators that will ever be resumed), which was my
point.

> I suspect that it would make the performance
> of modifying a document via iterators unacceptably poor.

Here I think the JDK 1.2 java.util.Iterator class is useful: it has
a "remove" method which removes the last element iterated to
in a safe way, or raises an exception if the underlying
container is read-only.
 
> Moving to per-node timestamps would reduce the amount of
> unnecessary invalidation, and preserve the O(1) check,
> but at the cost of making tree modifications O(log n).

Just so.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Fri Nov 13 17:18:05 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:32 2004
Subject: SAX Future
Message-ID: <3.0.32.19981113090224.00bc2d00@pop.intergate.bc.ca>

At 11:18 AM 11/13/98 -0500, John Cowan wrote:
>sets up a chain where SAXDriver (the real parser) passes
>to tinker, which passes to evers, which passes to chance, :-) which
>passes to the application.

Note to the other 83% of the readership: this is an erudite 
historical-baseball allusion.  We await with bated breath the
Roy Riegels metaphors. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 ifi.uio.no  Fri Nov 13 17:26:34 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:32 2004
Subject: SAX Future
In-Reply-To: <13898.64310.340243.918644@localhost.localdomain>
References: <012c01be0e15$91bae7c0$c5010180@p197> <13898.64310.340243.918644@localhost.localdomain>
Message-ID: <wkr9v7sdy3.fsf_-_@ifi.uio.no>


I think the main reasons that SAX has achieved such popularity as it
has (even being implemented by Oracle) are that it is very simple to
add SAX support to a parser, it arrived early and it has remained
stable.

Any attempts at making a SAX 2.0 (or 1.0.1) puts two of these reasons
in immediate jeopardy, and also creates a potential for endless
compatibility problems. On reflection I think we should be very
careful in developing a new version of SAX and attempt to break as
little as possible when/if doing so.

Some of the things that have been suggested can, I think, be safely
added without jeopardizing compatibility, since they are additions
above the driver level:

 - Parser filters
 - Driver management
 - More library functionality

I support all these and think they would be very useful. Some ideas
for how these could be done might be taken from the Python SAX
extensions, which are described at:

<URL:http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxexts-spec.html>
<URL:http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxutils-doco.html>


However, some of the other suggestions are a bit more troublesome:

 - A handler for basic lexical information
 - A handler for DTD information
 - The option for parsers not to break up PCDATA
 - Depending on the implementation driver querying might also end up 
   on this list

I think the lexical handler very useful, if only because it provides
information about the DOCTYPE declaration. I'm not so sure about the
handler for DTD information, which would most likely be much harder to
develop and also rather difficult to use in any sensible way.

As for the PCDATA option I agree with David in preferring a
ParserFilter for this purpose.

In spite of the potential problems I do support the driver querying
and management part. It's been very useful to us in Python, and now
that I'm doing some work in Java as well I wish I had it there too.

Being able to say

  saxexts.XMLValParserFactory.make_parser()

and knowing that you'll get a validating parser if one is installed
or else an exception is really convenient.


Finally, there is the question of backwards compatibility. As far as I
can see the extensions I labelled 'safe' can be done with no harm to
compatibility. The two new handlers are slightly trickier, but might
be incorporated in the same manner that SAX for Python did its
extensions: a separate sub-interface of Parser called ExtendedParser.

One could then add an implementation of ExtendedParser that wrapped
SAX 1.0 parsers and threw SAXUnsupportedExceptions when attempts were
made to call the new methods. This would avoid the need for a new
package name entirely.

The driver querying methods might get a separate interface or it might
be added to the ExtendedParser like in Python.


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


From sbagora at inacom.com  Fri Nov 13 17:45:06 1998
From: sbagora at inacom.com (Sudhanshu Bagora)
Date: Mon Jun  7 17:06:32 2004
Subject: Question about sending and receiving XML via ASP's
Message-ID: <862566BB.00617291.00@omaclnmta01.inacom.com>

Hi,

I am currently working on a project which passes XML back and forth via
ASP's.

The scenario is as follows:

1)  Page1.asp is creating an XMLBlock and passing it on to Page2.asp
2) Page2.asp saves the XMLBlock in a file and loads it, parses it and does
some processing.
Then Page2.asp forms another new ReturnXMLBlock which needs to be passed
back to Page1.asp

The method i am using to pass XMLBlock from Page1.asp to Page2.asp is

.....
XMLDoc.URL = "http://.... Page2.asp?XMLBlock=" + XMLBlock

....
Parse ReturnXMLBlock
......

and am expecting ReturnXMLBlock to be loaded in XMLDoc after this above
statement is processed.

This above operation is not successful.  I have tried to do it in IE4.0 as
well as IE5.0

The question i have is:

a)  Is this valid? Can i expect to get a new ReturnXMLBlock after the
XMLDoc.URL statement is processed.
b)  If it is valid -  What am i doing wrong?
c)  What would the syntax be in Page2.asp where i am returning the
ReturnXMLBlock? In Script tags or plain XML tags??

Any help would be greatly appreciated.

Thanks in advance.

-sudhanshu-



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Fri Nov 13 17:53:30 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:32 2004
Subject: Infoseek announces XML search engine
Message-ID: <3.0.32.19981113095212.00b56100@pop.intergate.bc.ca>



http://www.wired.com/news/news/technology/story/16221.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Fri Nov 13 18:06:23 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:32 2004
Subject: Infoseek announces XML search engine
In-Reply-To: <3.0.32.19981113095212.00b56100@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981113100459.00f0ab60@scripting.com>

Tim, when I spoke with Chris, I asked him to look at this piece I wrote
last year, about a pragmatic way search engines could use XML to broaden
their reach and catch more recent developments on the web. Here's the piece:

http://www.scripting.com/davenet/97/12/realWorldXml.html

And here's the prototype of the file the search engines could read:

http://www.scripting.com/siteChanges.xml

We did this stuff before I was on this list, since people often ask for
applications, and since otherwise the search engine-XML connection is not
well understood, I wanted to add this to the record, I think it's easy and
could be an important way for XML to quickly make the web more useful.

Dave

--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Fri Nov 13 18:38:01 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:32 2004
Subject: Data attributes (was: Stylesheets considered limiting)
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
	 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
	 <3.0.5.32.19981112075504.008d5b10@amati.techno.com> <3.0.5.32.19981112234611.0098ecd0@amati.techno.com>
Message-ID: <364C7D0B.BBEA4607@locke.ccil.org>

W. Eliot Kimber wrote:

> Sure.

Thank you.  Your writeup is very clear as always.
 
> <!NOTATION gif SYSTEM "ftp://ftp.isi.edu/">
> <!ATTLIST #NOTATION gif
>    width CDATA "100"
>    height CDATA "100">
> 
> <!ENTITY big-graphic SYSTEM "picture.gif" NDATA gif
>   [ width="640" height="480"]>

Okay.  Since XML cannot have references to unparsed entities*, the
above can be treated as syntactic sugar.  Specifically,

	<GRAPHIC pic="big-graphic"/>

is effectively syntactic sugar for:

	<GRAPHIC pic="big-graphic" gif.width="640" gif.height="480"/>

but bypassing the SGML/XML restriction that the validity or invalidity
of attributes cannot depend on the values of other attributes.
If "big-picture" were not a "gif" entity, the "gif.width" and
"gif.height" attributes would be invalid.

It would be very easy to create a ParserFilter on top of a
validating XML parser (so that we reliably get attribute types)
that processed the above declarations (wrapped in PIs)
and generated extra attributes of the type shown above.

*(Come to think of it, references to unparsed entities could be
seen as syntactic sugar for an anonymous empty element with a
single anonymous ENTITY attribute.)

> <!ATTLIST SelectData
>    notation NOTATION(MyQuery) MyQuery
>    table CDATA #REQUIRED
>    select-on CDATA #REQUIRED
>    where (name|ssnum|phone) #REQUIRED>

In this case, though, the notation attributes seem to blend with
the regular attributes, and are redeclared in the ATTLIST declaration
for the element.  What happens in the case of an element type that
can be governed by alternative notations?

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Fri Nov 13 18:43:37 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:32 2004
Subject: Back to XObjects was XLink - where a
References: <TFSIXERP@dpsl.co.uk>> <364B26B1.8A6AC5B@eng.sun.com>
Message-ID: <364C7AEE.810E91B3@eng.sun.com>

Responding to Graham's comment about binding elements to classes, I wrote:
> 
> I've got an API driven approach, which could be driven based on config
> files using an XML syntax like the one I suggested a while back.  But
> the API can also be driven in other ways, too.  ("Element Factory", an
> interface that can be implemented in many ways.  I'll post more later.)

It's "later", after a busy Thursday and a morning cuppa Java ...

	// to customize DOM tree building
	public interface ElementFactory {
		// like DOM createElement, used with namespaces disabled
		ElementEx createElementEx (String tag);

		// ... namespace aware version
		ElementEx createElementEx (String uri, String tag);
	}

	// implemented by elements and attributes for namespace support
	public interface NamespaceScoped extends Node {
		// returns "local part" of node name, no prefix
		String getLocalName ();

		// returns URI of namespace, null for default
		String getNamespace ();
	}

	// extended element functionality
	public interface ElementEx extends Element, NamespaceScoped {
		// namespace-aware
		String getAttribute (String uri, String name);

		// namespace-aware
		Attr getAttributeNode (String uri, String name);

		// basic delegation hook
		Object getUserObject ();

		// basic delegation hook
		void setUserObject (Object obj);

		// has more, for other purposes ...
		...
	}

That "user object" bit is a delegation hook; it's just stored for use by
applications.  Supports many-to-one association of elements to objects in
an application model, no backlink.  I don't know if it suffices, but I
suspect that any more would become specific to some problem domain.

For the moment, I'm not listing the DocumentBuilder bit here.  Basically,
you can feed an ElementFactory in to a DocumentBuilder and it'll use it
when building the DOM tree; if you don't, it has defaults.  And there's a
simple table-driven implementation that's easily customized.  (Maybe it'll
learn a standard "config file" syntax -- in XML of course!)

Other implementations are clearly possible, including ones using heuristics
like those like James Anderson posted.

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


From avirr at LanMinds.Com  Fri Nov 13 19:24:14 1998
From: avirr at LanMinds.Com (Avi Rappoport)
Date: Mon Jun  7 17:06:32 2004
Subject: Infoseek announces XML search engine
In-Reply-To: <3.0.32.19981113095212.00b56100@pop.intergate.bc.ca>
Message-ID: <v04102d05b2722fa13547@[207.33.50.55]>

At 9:53 AM -0800 11/13/98, Tim Bray wrote:
> http://www.wired.com/news/news/technology/story/16221.html

Thanks, Tim, for the pointer.

The Infoseek Ultraseek page is at:

<http://software.infoseek.com/products/ultraseek/ultratop.htm>

but there is no info there yet on the version 3.0.

Avi
________________________________________________________________
Avi Rappoport, Web Site Search Tools Maven: <mailto:avirr@lanminds.com>
Guide to Site Indexing and Local 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Fri Nov 13 21:59:30 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:33 2004
Subject: Data attributes (was: Stylesheets considered limiting)
In-Reply-To: <364C7D0B.BBEA4607@locke.ccil.org>
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
 <3.0.5.32.19981112234611.0098ecd0@amati.techno.com>
Message-ID: <3.0.5.32.19981113155708.00a017c0@amati.techno.com>

At 01:40 PM 11/13/98 -0500, John Cowan wrote:

> <!ENTITY big-graphic SYSTEM "picture.gif" NDATA gif
>   [ width="640" height="480"]>

Okay.  Since XML cannot have references to unparsed entities*, the
above can be treated as syntactic sugar.  Specifically,

	<GRAPHIC pic="big-graphic"/>

is effectively syntactic sugar for:

	<GRAPHIC pic="big-graphic" gif.width="640" gif.height="480"/>

Not necessarily. What if I have this situation:

<!NOTATION MyQuery PUBLIC "">
<!NOTATION GIF PUBLIC "" >
<!ENTITY mygif SYSTEM [ width="640" height="480" ]>

...
<Query notation="MyQuery" icon="mygif">find something</Query>

Here, the notation of the element governs the query--the graphic it
references is just presentation stuff in this case. So I can't put the
entity's attributes on the element as well--they represent two different
semantic domains, that of the query (represented by the element) and that
of the graphic, represented by the entity.  Without data attributes and the
ability to specify them as part of an entity declaration, I cannot keep
these two domains clearly and unambiguously separate.

>> <!ATTLIST SelectData
>>    notation NOTATION(MyQuery) MyQuery
>>    table CDATA #REQUIRED
>>    select-on CDATA #REQUIRED
>>    where (name|ssnum|phone) #REQUIRED>
>
>In this case, though, the notation attributes seem to blend with
>the regular attributes, and are redeclared in the ATTLIST declaration
>for the element.  What happens in the case of an element type that
>can be governed by alternative notations?

If the attributes are explicitly declared, its attributes have to be the
union of the attributes for all the possible governing notations.  However,
if you only declare the notations and not the attributes (or even the
element type), then there's no redundancy of declaration as long as you
specify the notation.  You can only specify one notation per element
instance (which might be a design bug now that I think about it--I can
thing of cases where the same element might be reasonably governed by
different notations relevant to different processing domains).

One of the things that the notation attributes do is make it clear that a
particular attribute of an element should be (or can be) relevent to the
notation  that governs the element.  

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Sat Nov 14 05:31:53 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:33 2004
Subject: XLink - where are we? [tiny amount of frustration]
In-Reply-To: <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
References: <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981113233212.009b5300@amati.techno.com>

At 09:03 PM 11/11/98, Peter Murray-Rust wrote:

>I am probably tilting at windmills but I am attempting something like this
>in JUMBO - I have about 5 approaches to styles without stylesheets.
>(a) redisplay it as raw XML. Not as silly as it sounds for many documents.
>(b) pretty-print it and display as XML. Extremely useful for many documents
>(c) Reformat start tags as bold and add NL after PCDATA. Works pretty well
>for many documents.
>(d) map every element onto a Java class. 
>(e) allow the user to customise some or all elements with styles. I shall
>use Swing for the rendering. Then, I suppose I could write the styles out
>as XSL if anyone cares.

Below is a DSSSL style sheet that implements a simple form of option (b). I
have tested this with the latest HyBrick and with Jade.  It should be
usable by itself (no other catalog configuration needed).  Choose it as the
style for those documents that don't already have one.  It's simple enough
that you should be able to figure out how to adjust it to your own taste
without having the DSSSL spec to hand.

Note that HyBrick's Xlink support doesn't require any style work, so
documents using this style sheet will still exhibit their Xlink-defined
behavior.

Cheers,

E.
--- cut here ---
<!doctype dsssl-spec [
<!element dsssl-spec o o
  (char-repertoire?, style-specification,
    (style-specification|external-specification)*)>
<!ATTLIST dsssl-spec
  id
    ID
    #IMPLIED
>
<!element style-specification o o (style-specification-body)>
<!element style-specification-body o o (#pcdata)>
<?IS10744 ArcBase dsssl>
<!notation dsssl PUBLIC
  "ISO/IEC 10179:1996//NOTATION DSSSL Architecture Definition Document//EN">
<!entity % dssslDtd system "dsssl.dtd">
<!attlist #notation dsssl
  ArcDocF NAME #FIXED dsssl-specification
  ArcDTD CDATA "%dssslDtd"
  ArcQuant CDATA "NAMELEN 64"
>
<?stylesheet href="tagview.dsl" type="text/dsssl">
]>
<dsssl-spec id="foo">
;------------------------------------------------------------
; "Tag View" DSSSL Spec. Provides a default style for
; SGML or XML documents.
;
; Author: W. Eliot Kimber
;
;
; Change History:
;
; $Header$
;
; $Log$
;
;--------------------------------------------------------------------------

(define debug
  (external-procedure "UNREGISTERED::James Clark//Procedure::debug"))

(define *rgb-color-space*
  (color-space "ISO/IEC 10179:1996//Color-Space Family::Device RGB"))

(define midnight-blue-color
  (color *rgb-color-space* (/ 25 255) (/ 25 255) (/ 112 255)))

(define primary-blue-color
  (color *rgb-color-space* (/ 25 255) (/ 25 255) (/ 255 255)))

(define sea-green-color
  (color *rgb-color-space* (/ 46 255) (/ 139 255) (/ 87 255)))

(define red-color
  (color *rgb-color-space* (/ 255 255) (/ 0 255) (/ 0 255)))

;--------------------------------------------------
; Define general-purpose functions:
;--------------------------------------------------

(define (copy-attributes nd indent)
  (let loop ((atts (named-node-list-names (attributes nd)))
             (resultstr ""))
    (if (null? atts)
        resultstr
        (loop
          (cdr atts)
          (let* ((name (car atts))
                 (value (attribute-string name nd)))
            (if value
              (string-append
                resultstr
                "&#RE;"
                indent
                name
                "=\""
                value
                "\"")
              resultstr))))))

(define (ancestors nl)
  (node-list-map
    (lambda (snl)
      (let loop
        ((cur (parent snl))
         (result (empty-node-list)))
        (if (node-list-empty? cur)
          result
          (loop (parent cur)
                (node-list cur result)))))
    nl))

(define (copy-string string count)
  (let loop ((resultstr "")
             (count count))
    (if (equal? count 0)
      resultstr
      (loop (string-append resultstr string)
            (- count 1)))))

(declare-initial-value font-family-name "iso-monospace")

(root
  (make scroll
    (process-children)))

(default
  (let ((indent
          (copy-string
            "  "
            (node-list-length (ancestors (current-node))))))
    (sosofo-append
      (make paragraph
        color: sea-green-color
        (literal
          indent
          "<"
          (gi (current-node))
          (copy-attributes (current-node) (string-append indent "  "))
          ">"))
      (make paragraph
        lines: 'asis
        (process-children))
      (if (node-property 'must-omit-end-tag?   (current-node))
        (empty-sosofo)
        (make paragraph
          color: sea-green-color
          (literal
            indent
            "</"
            (gi (current-node))
            ">"))))))
;--- end of spec 
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sblackbu at erols.com  Sat Nov 14 11:52:17 1998
From: sblackbu at erols.com (Samuel R. Blackburn)
Date: Mon Jun  7 17:06:33 2004
Subject: Creation of XML documents
Message-ID: <006201be0fc5$42e80b30$01010101@sammy>

If a non-validating C++ library will help, take a look at the
XML classes in the freeware Win32 Foundation Classes (WFC)
at http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm

HTH,

Sam

-----Original Message-----
From: Richard Anderson <RJA@arpsolutions.demon.co.uk>
To: XMLDEV <xml-dev@ic.ac.uk>; Wester, JJ (ICT) <j.j.wester@kpn-telecom.nl>
Date: Friday, November 13, 1998 10:26 AM
Subject: Re: Creation of XML documents


>> I would like to have a 'library' to which the application developer
>> could say 'using this DTD please
>> instantiate a XML document and help me to fill it in'.
>
>I've got a C++ toolkit that is under development that sort of mets these
>requirements. It has a SAX+DOM interface.   ( The COM variant will follow
>very shortly for use in VB etc )
>
>Using the SAX interface you can build a 'template' DOM and then fill in the
>missing bits.
>
>The toolkit has *no* dependancies on MSIE etc.
>
>Heres some sample code for creating an XML EMAIL:
>
>************ CODE SECTION START ****************
>
>pDoc = pDOMAPI->createDocument();
> pRootElement = pDoc->createElement( L"EMAIL" );
>pFrom = pDoc->createElement( L"From" );
> pRootElement->appendChild( pFrom );
>pFrom->setAttribute( L"Priority", L"High" );
> pFrom->setAttribute( L"DeliveryReceipt", L"Yes" );
> pFrom->setAttribute( L"ReturnReceipt", L"Yes" );
>
>pText = pDoc->createTextNode( L"RJA@arpsolutions.demon.co.uk" );
>pFrom->appendChild( pText );
>
>pTo = pDoc->createElement( L"To" );
>pRootElement->appendChild( pTo );
>pText = pDoc->createTextNode( L"enquires@arpsolutions.demon.co.uk" );
>pTo->appendChild( pText );
>
>pSubject = pDoc->createElement( L"Subject" );
>pRootElement->appendChild( pSubject );
>pText = pDoc->createTextNode( L"XML/DOM/SAX C++ Toolkit" );
>pSubject->appendChild( pText );
>
>pComment = pDoc->createComment(L"Main body of Email follows");
>pRootElement->appendChild( pComment );
>pBody = pDoc->createElement( L"Body" );
>pRootElement->appendChild( pBody );
>
>pText = pDoc->createTextNode( L"Seems OK so far." );
>pBody->appendChild( pText );
>
>pText = pDoc->createTextNode( L"I'll have to try harder to break it." );
>pBody->appendChild( pText );
>
>pPI = pDoc->createProcessingInstruction(L"PI",
>                                          L"That's all folks!" );
>
>pCC = pDoc->createElement( L"CC" );
>pText = pDoc->createTextNode( L"xml_toolkit@arpsolutions.demon.co.uk" );
>pCC->insertBefore( pText, NULL );
>pRootElement->insertBefore( pCC,pTo );
>
>CStdioWideStream stream;
>pDOMAPI->writeXML( pRootElement, &stream );
>
>*********** CODE SECTION END ***************
>
>If your interested I can send you the C++ alpha toolkit.
>
>Regards,
>
>Richard.
>
>***********************************************
>* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
>* WEB     http://www.arpsolutions.demon.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/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 ifi.uio.no  Sat Nov 14 13:55:25 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:33 2004
Subject: XSA: Almost ready to go
Message-ID: <wk3e7mgz2v.fsf@ifi.uio.no>


I'm pleased to announce that one XML application that actually uses
XML for exchanging informaation over the network and automatically
acting on it is almost ready for use. The XSA system I proposed here
earlier this year[1] has now been polished, documented and had
software developed for it.

The system is now going into beta for a while until I'm satisfied that
all bugs have been shaken out of the software and that nobody will
come forth and demand changes to the system. This should hopefully
only take a couple of weeks.

So anyone who is interested is invited to have a look at the XSA web
site at

<URL:http://birk105.studby.uio.no/www_work/xsa/>

Any feedback on the site, the system or the code is most welcome.


When I first suggested this there was some talk about coordinating
this with Trove, LSM and OSD. These avenues have been explored, and
have so far only lead to adding support for OSD to the system, mainly
because these systems had other goals than XSA has.

--Lars M.

[1] <URL:http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0147.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Sat Nov 14 16:28:37 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:33 2004
Subject: ISO/IEC Standardization Activities: Procedural Background
Message-ID: <3.0.5.32.19981114101714.008a33a0@amati.techno.com>

[Warning: boring but important standards stuff. Please read to the end if
you can.]

The ISO group responsible for the SGML family of standards was recently
promoted from a working group to an ISO subcommittee (SC). What was ISO/IEC
JTC1/WG4 (nee SC18/WG8)is now ISO/IEC JTC1/SC34 Information Technology -- 
Document Description and Processing Languages (see
<http://www.ornl.gov/sgml/sc34/sc34home.htm>).  We had our first meeting as
an SC this last week. At this meeting we approved the organization of SC34
into three working groups:  WG1 covers representation languages (SGML,
SDIF, etc.), WG2 covers fonts and styles (DSSSL, etc.),  and WG3 covers
"relations", that is, hyperlinking and the like (HyTime, ISO HTML, ISMID,
Topic Maps). Note that this does *NOT* include media formats like MHEG or
JPEG, APIs like CORBA, or networking protocols.

I am acting convenor of WG3 (and will likely be accepted as convenor when
permanent convenors are selected).

As convenor of WG3 I'd like to stress the desire of WG3 that the standards
we produce be both compatible with and useful for XML-based data and
applications. I'd also like to stress our desire to be as open and
inclusive as we possibly can be within the constraints ISO imposes.

The constraints on us are entirely procedural--we have no secrecy
requirements as far as I know (but I could be wrong--this is a bit of a
bureaucratic morass). The only real limitation on participation is the
ability to attend the formal ISO meetings.  However, anyone is free to
review and comment on any of the standards under development and published
as official SC34 documents.  It is up to the editors of each standard to
define how they do their development and can involve anyone they feel like.  

The procedural constraint is on how comments get officially communicated to
the editors. Once a standard has reached a state of near completion, the
ISO policies are designed to ensure that the editorial process is as
visible as possible.  It is designed to make last-minute changes visible to
the voting member bodies (and observing public) and help ensure that major
design decisions are not made at the last minute.

The current ISO stages for draft standards are "committee draft", "final
committee draft", and "draft international standard" (DIS). Committee
drafts are works in progress and can be quite dynamic as the editors do
their work. Final committee drafts are supposed to be true final drafts,
requiring only minor changes before progressing to draft international
standard. However, several final committee drafts can be issued before a
standard goes to DIS stage [I know, it's doublespeak--I didn't make this
stuff up, I just try to work within the rules I've been given.]

The key thing is that once a standard reaches final committee draft stage,
the editors are constrained to only making changes that correspond to
comments submitted by member bodies.  The member body comments are formal
SC34 documents that everyone can see.  This helps ensure that there are no
surprises when the DIS draft is sent for ballot.  Unfortunately, it also
slows down the editorial process because each new FCD requires a new ballot
period of 2-4 months.

What does this mean to you, the average XML-Dev techie?

It means that if you are interested in one of WG3's standards and have some
constructive comments on it AND that standard is in final committee draft
state, THEN you must forward your comments to a member of one of the
national delegations to SC34.  If the standard is just a committee draft
then you can communicate with the editors directly. If you don't know how
to contact the editors, send me mail and I'll hook you up.

If you are not in the U.S. and you do know who your SC34 representative or
head of delegation is, then you can just forward your comments to them.
They should evaluate your comments and, if they are factually correct and
also consistent with the overall national opinions on the standard,
integrate them with any others they have and submit them as part of the
formal process. If your comments are not consistent with the national
opinion, they should work with you to understand the technical issues to
make sure your concerns have gotten a fair consideration.  They should also
give your name to the editors of the standard so that they can communicate
with you to better understand your comments. [Note: the time order of these
actions is not exposed by the formal process.]

NOTE: Each national body defines it's own rules and policies for how it
develops its responses to ballots and requests for comment.  The above is
the suggested policy for WG3 participants. I can't guarantee that any
particular member body will be receptive to unsolicited comments. However,
I think it's safe to say that the currently active member bodies are all
receptive to comments from anyone with legitimate and constructive
technical insight.

If you are in the U.S., or you don't know who your SC34 delegates are (and
I don't know why you would--we're not exactly international celebrities),
you can forward your comments to me in my capacity as a member of the U.S.
delegation to SC34 and I will either incorporate your comments with ours or
pass them on to the appropriate national body, if there is one (not all ISO
members send delegations to SC34).

Our interest in WG3 is to produce standards that are relevant, useful, and
technically sound. I want to make the process of developing our standards
as open and productive as possible.  To that end, I will periodically make
announcements here of WG3 activity that I think is relevant or of potential
interest to the XML developer community.

Thanks,

Eliot
Acting Convenor, ISO/IEC JTC1/SC34/WG3 
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Sat Nov 14 16:28:41 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:33 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
  Ballot
Message-ID: <3.0.5.32.19981114102847.008a5e10@amati.techno.com>

The Topic Navigation Map (Topic Map) standard, ISO/IEC 13250, is out for
ballot to become a final committee draft, the last stage before becoming a
full standard.  You can find the draft being balloted at
<http://www.ornl.gov/sgml/sc34/document/0008.htm>. This ballot lasts until
the end of February. However, in order to progress the standard as quickly
as possible, we'd like to get comments to the editors before the end of the
year.

The Topic Map standard is similar to RDF in some ways (but has an
essentially different focus and intended domain of application). It is also
designed to be implementable using Xlink.  It defines a relatively simple
(but still powerful) approach to representing rich relationships among
information objects.

If you are working with Xlink, especially extended links, or thinking about
how you might use them productively, I urge you to take a look at the
standard.  I have started putting together some examples, both to test the
standard and to use in my Xlink class.  I will be posting these as soon as
possible, hopefully within the week. 

NOTE: some of the prose in the standard is currently a bit dense and
abstract. the U.S., France, and Norway have developed comments against the
current draft that should help to make things much clearer (we hope).  If
you're trying to read the standard and not getting it, send me mail and
I'll see what I can do to help.  The editors are already working on fixing
these problems, but they can't be made officially visible at this time
because of process constraints.

We all think that topic maps could be a really interesting application of
Xlink. They are, I think, relevant to some of the work that Peter
Murry-Rust has been doing on developing online glossaries and the like.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From dave at userland.com  Sat Nov 14 17:04:22 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:33 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
   Ballot
In-Reply-To: <3.0.5.32.19981114102847.008a5e10@amati.techno.com>
Message-ID: <3.0.5.32.19981114084806.00ef89b0@scripting.com>

What kind of applications would we use the Topic Map structures for? 

It always helps me to understand this kind of stuff if I can understand a
compelling application for it.

Dave

At 10:28 AM 11/14/98 -0600, you wrote:
>The Topic Navigation Map (Topic Map) standard, ISO/IEC 13250, is out for
>ballot to become a final committee draft, the last stage before becoming a
>full standard.  You can find the draft being balloted at
><http://www.ornl.gov/sgml/sc34/document/0008.htm>. This ballot lasts until
>the end of February. However, in order to progress the standard as quickly
>as possible, we'd like to get comments to the editors before the end of the
>year.
>
>The Topic Map standard is similar to RDF in some ways (but has an
>essentially different focus and intended domain of application). It is also
>designed to be implementable using Xlink.  It defines a relatively simple
>(but still powerful) approach to representing rich relationships among
>information objects.
>
>If you are working with Xlink, especially extended links, or thinking about
>how you might use them productively, I urge you to take a look at the
>standard.  I have started putting together some examples, both to test the
>standard and to use in my Xlink class.  I will be posting these as soon as
>possible, hopefully within the week. 
>
>NOTE: some of the prose in the standard is currently a bit dense and
>abstract. the U.S., France, and Norway have developed comments against the
>current draft that should help to make things much clearer (we hope).  If
>you're trying to read the standard and not getting it, send me mail and
>I'll see what I can do to help.  The editors are already working on fixing
>these problems, but they can't be made officially visible at this time
>because of process constraints.
>
>We all think that topic maps could be a really interesting application of
>Xlink. They are, I think, relevant to some of the work that Peter
>Murry-Rust has been doing on developing online glossaries and the like.
>
>Cheers,
>
>Eliot
>--
><Address HyTime=bibloc>
>W. Eliot Kimber, Senior Consulting SGML Engineer
>ISOGEN International Corp.
>2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
>www.isogen.com
></Address>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
>
>

--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sat Nov 14 18:48:27 1998
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:06:33 2004
Subject: Data attributes (was: Stylesheets considered limiting)
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
	 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
	 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
	 <3.0.5.32.19981112234611.0098ecd0@amati.techno.com> <3.0.5.32.19981113155708.00a017c0@amati.techno.com>
Message-ID: <364DD0B0.62F3BCC@mecomnet.de>

the situation described below is a case where a namespace prefix is well used
to ensure unambiguous naming. if one uses the notation or entity name as the
name prefix it awards the same expressive power as the implicit qualification
of data attributes.

W. Eliot Kimber wrote:
> 
> ...
> 
> Not necessarily. What if I have this situation:
> 
> <!NOTATION MyQuery PUBLIC "">
> <!NOTATION GIF PUBLIC "" >
> <!ENTITY mygif SYSTEM [ width="640" height="480" ]>
> 
> ...
> <Query notation="MyQuery" icon="mygif">find something</Query>
> 
> Here, the notation of the element governs the query--the graphic it
> references is just presentation stuff in this case. So I can't put the
> entity's attributes on the element as well--they represent two different
> semantic domains, that of the query (represented by the element) and that
> of the graphic, represented by the entity.  Without data attributes and the
> ability to specify them as part of an entity declaration, I cannot keep
> these two domains clearly and unambiguously separate.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From creitzel at mediaone.net  Sat Nov 14 20:24:08 1998
From: creitzel at mediaone.net (Charles Reitzel)
Date: Mon Jun  7 17:06:33 2004
Subject: New SAX Version
Message-ID: <199811142023.PAA05204@chmls06.mediaone.net>

1) Agree w/ David Megginson's priorities:

>... the following for SAX 1.0 are probably higher priorities:
>
>1. A proper specification for SAX (JavaDoc just doesn't cut it).
>2. A test suite for SAX conformance.
>3. Canonical SAX interfaces for Perl (on top of XML:Parser) and C++.

I volunteer to work on a C++ implementation.

2) Some additional SAX features (e.g. driver/filter manager, Element/Object
factory) are "orthogonal" to the core interfaces.  Why not create separate
packages for these?  A default rule like "Additional SAX packages will
depend only on the core package" will keep things manageable.  

3) Isn't it too soon to freeze any XML related specs because of the
"installed base"?  I think the time tested approach is to maintain existing
interfaces for backward compatibility for release or three after they are
officially deprecated.  Sometimes this means that new names must be used
where you would prefer not to but, hey, that's life in the big city.  An
update once a year won't thrash anybody's code.  So, it's better to get in
fixes for those few wee problems with the core API's than wait for the
installed base to grow by an order of magnitude and it really will have to
freeze.

4) Is it a good idea to hard-wire each SAX version to an XML version?  I
think ODBC would be a pretty good model to follow here.  Each version of the
driver manager (ODBC itself) defines how it will interact with drivers
written for earlier versions of ODBC.  ODBC v2 can handle v2 and v1, etc.
ODBC pretty much froze a v2 because a) it was pretty complete and b) the
installed base became huge.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From lisarein at finetuning.com  Sat Nov 14 23:37:14 1998
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun  7 17:06:33 2004
Subject: Oracle XML
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org> <364AB030.EFAC2ADE@sophia.inria.fr> <364B6296.3598F440@infinet.com>
Message-ID: <364E030D.FD0F3655@finetuning.com>

actually -- all this says to me is that they never even ran it through a
parser...(not even once :-)   

Not good for a high-profile document that many others will attempt to
emulate....

I say - bad dog - no biscuit!

lisa

Tyler Baker wrote:
> 
> "Philippe Le H?garet" wrote:
> 
> > K. Travis Walsh wrote:
> > >
> > > Oracle officially anounced today it's XML strategy.
> > >
> > > For those of you who didn't know there is a java parser built into this
> > > new release of Oracle 8i.
> >
> >   Like netscape, They can't write well-formed XML document.
> >
> >   <?xml version="1.0"> is not a well-formed XML document.
> >
> 
> Hey give them a break.  Forgetting that little question mark is something
> everyone has done from time to time when handcrafting XML documents.  I know,
> cause I have done this many times.  If XML did not inherit SGML's syntax, I bet
> we would all of a much cleaner syntax to work with with less user errors as a
> result.
> 
> 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/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Sun Nov 15 05:03:08 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:33 2004
Subject: Oracle XML
In-Reply-To: <364E030D.FD0F3655@finetuning.com>
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
 <364AB030.EFAC2ADE@sophia.inria.fr>
 <364B6296.3598F440@infinet.com>
Message-ID: <199811150502.AAA05690@hesketh.com>

Tyler Baker wrote:
> 
> "Philippe Le H?garet" wrote:
> 
> > K. Travis Walsh wrote:
> > >
> > > Oracle officially anounced today it's XML strategy.
> > >
> > > For those of you who didn't know there is a java parser built into this
> > > new release of Oracle 8i.
> >
> >   Like netscape, They can't write well-formed XML document.
> >
> >   <?xml version="1.0"> is not a well-formed XML document.
> >
> 
> Hey give them a break.  Forgetting that little question mark is something
> everyone has done from time to time when handcrafting XML documents.  I
know,
> cause I have done this many times.  If XML did not inherit SGML's syntax,
I bet
> we would all of a much cleaner syntax to work with with less user errors
as a
> result.
> 
> Tyler

All right, already.  Why is this worthy of a posting to XML-Dev rather than
a polite note to their Webmaster?  Proving that you know more about XML
than Oracle and Netscape, however easy and gratifying that may be, doesn't
further the knowledge base of the XML community in any way that I at least
consider significant.

Could we help people and companies fix problems rather than broadcast
problems onto the largest screen possible?  Pointing out problems like this
only makes XML's oddities seem like more of a barrier to 'proper'
development than they really are.


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 15 13:05:01 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:33 2004
Subject: Definitive test suite? (was Re: Oracle XML)
In-Reply-To: <199811150502.AAA05690@hesketh.com>
References: <364E030D.FD0F3655@finetuning.com>
 <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
 <364AB030.EFAC2ADE@sophia.inria.fr>
 <364B6296.3598F440@infinet.com>
Message-ID: <3.0.5.32.19981115050420.00f3b990@scripting.com>

Simon, it's going to get a lot worse before it gets better. There are a
billion parsers being written right now, all will accept different flavors
of XML. 

There still is no definitive test suite of XML files they have to parse. If
we're serious about having compatibility and offering users real choices,
we can probably still fix this, but soon, the cat will be out of the bag,
as they say, and it'll be too late. 

No individual commercial vendor has the credibility or motivation to
establish this test suite. But a famous book author or two could do it. ;->

Dave

--------------------------------------
http://www.userland.com/directory.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Sun Nov 15 14:51:09 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:33 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
    Ballot
In-Reply-To: <3.0.5.32.19981114084806.00ef89b0@scripting.com>
References: <3.0.5.32.19981114102847.008a5e10@amati.techno.com>
Message-ID: <3.0.5.32.19981115084029.0099ebf0@amati.techno.com>

At 08:48 AM 11/14/98 -0800, Dave Winer wrote:
>What kind of applications would we use the Topic Map structures for? 
>
>It always helps me to understand this kind of stuff if I can understand a
>compelling application for it.

A topic map consists, fundamentally, of two kinds of things: topics and
associations. A topic is an object that represents a single rhetorical
topic or subject. For example, "XML parser" might be one topic in a topic
map about XML. A topic serves to associate the abstract idea of the topic
with occurrences of that topic:

<topic xml:link="extended" role="topic" id="xml.parser">
<name>
<basename>XML Parser</basename>
</name>
<occur xml:link="locator" role="parser-instance"
       href="http://www.jclark.com/xp"/>
<occur xml:link="locator" role="parser-instance"
       href="http://www.microsoft.com/msxml/">
</topic>

Notice that this serves to impose the semantic label "XML Parser" onto the
occurrences addressed by the occur element.  Thus a topic can assert that a
given object is an occurrence of some kind of thing.  This lets you
construct a classfication or descriptive layer on top of existing data.
The topics essentially represent opinions about the data.  Different topic
map authors might express different opinions about the same data. Because
the form the opinions are expressed in is standardized and consistent
(topics), they can be reasonably compared to some degree.

Because the topics are expressed formally as hyperlinks (here using Xlink,
but also doable using HyTime), they are naturally navigable using whatever
hyperlinking support you have lying about (e.g., HyBrick, PHyLIS, etc.).

Associations relate topics to each other. To continue the XML topic map
idea,  might have a relation "standard-interface-for" that I use to relate
the topic "XML parser" to the topic "SAX":

<assoc role="standard-interface-for" xml:link="extended">
<assocrl role="parser" href="#id(xml.parser)" xml:link="locator"/>
<assocrl role="interface" href="#id(sax)" xml:link="locator"/>
</assoc>

In many ways, this is like RDF: you can impose properties onto data objects
and relate data objects together using typed links.  It may be that topic
maps are one way to express RDF abstractions, I don't know (I don't know
enough about RDF).  But while RDF seems to be designed primarily to support
the addition or representation of metadata about objects, topic maps are
designed for the creation of knowledge bases imposed on data of any type,
and, in particular.  In any case, Topic Maps are not intended to compete
with RDF--they are, in essence, different views of the same abstraction:
objects with properties and relations among them.

So what would you use topic maps for? I think one compelling use is as an
annotative or descriptive layer over things like encyclopedias,
dictionaries, databases, and the like. They might be used to enhance
management information systems by providing a simple but rich and
standardized way to capture analysis applied to existing data, such as
market reports, sales numbers, etc.

Topic maps can be a way to augment search and retrieval by providing a form
of index over a larger, more amorphous body of data. 

Many documents can be turned into topic maps simply by labeling the
existing components as topics. For example, you can think of a command
reference document as a topic map where every command description is a topic.

The reason for standardizing this concept is that it lets you build generic
topic map engines that understand the specific properties of topics and
associations and can therefore manage knowledge of those properties in a
crisp and efficient way, making the information available to processing
systems. It also allows the meaningful and automatic merging of topic maps
because it's clear how the components of each relate to each other as objects.

I'm not sure I've answered the question very well, but maybe I've provided
enough of a taste for what topic maps do that applications will suggest
themselves.  I've left out a number of important and interesting details in
the discussion above, but I think I've conveyed the flavor.

Cheers,

Eliot
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Sun Nov 15 14:51:10 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:34 2004
Subject: Data attributes (was: Stylesheets considered limiting)
In-Reply-To: <364DD0B0.62F3BCC@mecomnet.de>
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
 <3.0.5.32.19981112234611.0098ecd0@amati.techno.com>
 <3.0.5.32.19981113155708.00a017c0@amati.techno.com>
Message-ID: <3.0.5.32.19981115084926.008d6c60@amati.techno.com>

At 07:49 PM 11/14/98 +0100, james anderson wrote:
>the situation described below is a case where a namespace prefix is well used
>to ensure unambiguous naming. if one uses the notation or entity name as the
>name prefix it awards the same expressive power as the implicit qualification
>of data attributes.

I don't think it works though, because you don't know for sure that a given
prefixed attribute is associated with a given entity--besides entity names
are not, as far as I know, definable as namespace prefixes (that is, if a
prefix happens to be spelled the same as an entity name, there's nothing
that defines a necessary relationship between the two).

If entity names were automatically name-space names it means that the
name-space name space and the entity name space were irrevocalby combined.
This would be pretty odd, I think, and certainly violate the basic
principle of distinct name spaces staying distinct. By constrast, with the
notation attribute mechanism, the elements attribute name space and
notations attribute name space are only combined when the author or DTD
designers do so by choice.  And in any case, the Data Attributes for
Elements facility provides a mechanism for disambiguating names in the two
spaces when there are clashes.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jtauber at jtauber.com  Sun Nov 15 16:54:12 1998
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun  7 17:06:34 2004
Subject: Definitive test suite? (was Re: Oracle XML)
Message-ID: <005501be10b8$1a0c6780$0300000a@othniel.cygnus.uwa.edu.au>

-----Original Message-----
From: Dave Winer <dave@userland.com>
>There still is no definitive test suite of XML files they have to parse.

Well, there's James Clark's.

>No individual commercial vendor has the credibility or motivation to
>establish this test suite.

OASIS is just the group to have the credibility AND motivation and I believe
they are doing it.

James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Associate Researcher, Electronic Commerce Network
Curtin University of Technology, Perth, Western Australia

Maintainer of : www.xmlinfo.com,  www.xmlsoftware.com and www.schema.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov 15 19:56:06 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:34 2004
Subject: Oracle XML
References: <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org> <364AB030.EFAC2ADE@sophia.inria.fr> <364B6296.3598F440@infinet.com> <364E030D.FD0F3655@finetuning.com>
Message-ID: <364F320D.7A35A804@infinet.com>

Lisa Rein wrote:

> actually -- all this says to me is that they never even ran it through a
> parser...(not even once :-)

Or worse yet, their parser is non-conformant...

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov 15 20:05:31 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:34 2004
Subject: Definitive test suite? (was Re: Oracle XML)
References: <364E030D.FD0F3655@finetuning.com>
	 <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
	 <364AB030.EFAC2ADE@sophia.inria.fr>
	 <364B6296.3598F440@infinet.com> <3.0.5.32.19981115050420.00f3b990@scripting.com>
Message-ID: <364F3447.BDA9440@infinet.com>

Dave Winer wrote:

> Simon, it's going to get a lot worse before it gets better. There are a
> billion parsers being written right now, all will accept different flavors
> of XML.
>
> There still is no definitive test suite of XML files they have to parse. If
> we're serious about having compatibility and offering users real choices,
> we can probably still fix this, but soon, the cat will be out of the bag,
> as they say, and it'll be too late.
>
> No individual commercial vendor has the credibility or motivation to
> establish this test suite. But a famous book author or two could do it. ;->
>
> Dave

Jim Clark's test suite, though not perfect is a wonderful test suite that has
helped me out immensely.  If there should be any standard test suite for XML 1.0,
I would suggest Mr. Clark's.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov 15 23:20:57 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:34 2004
Subject: Definitive test suite? (was Re: Oracle XML)
In-Reply-To: James Tauber's message of Mon, 16 Nov 1998 00:50:48 +0800
Message-ID: <858.199811152320@doyle.cogsci.ed.ac.uk>

> >There still is no definitive test suite of XML files they have to parse.
> 
> Well, there's James Clark's.

Absolutely.  I have found this very useful.  It has a particularly
good range of not-well-formed cases.  The main area where it is
lacking is well-formed but invalid documents.

-- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Mon Nov 16 00:48:50 1998
From: SMUENCH at us.oracle.com (Steve Muench)
Date: Mon Jun  7 17:06:34 2004
Subject: Oracle XML
Message-ID: <199811160048.QAA19006@mailsun3>

Thanks, Simon.  
  
Indeed if the previous critic reads forward to Figure 9, he'll see  
the properly formatted XML PI in the example. I had fixed those two typos  
in a final review but they didn't make it into what got pushed out   
to the public website.  
  
David Megginson quietly informed me the URL for SAX in the document  
needed updating, too, so both corrections should be imminent.  
  
Take care.  
 
____________________________________________________________________________ 
 Steve  | Consulting PM & XML Technology Evangelist | smuench@oracle.com 
 Muench |      Java Business Objects Dev Team       | geocities.com/~smuench 

-------------- next part --------------
An embedded message was scrubbed...
From: "Simon St.Laurent" <simonstl@simonstl.com>
Subject: Re: Oracle XML
Date: 14 Nov 98 21:05:15
Size: 3766
Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981116/88ac4615/attachment.eml
From Suli.Ding at geis.ge.com  Mon Nov 16 01:51:33 1998
From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS))
Date: Mon Jun  7 17:06:34 2004
Subject: Document to XML Convertor
Message-ID: <F2A665AC0054D1119D0F00805FFECA120191530E@roc01bxgeisge>

Peter,

Very good question. I spent part of this weekend to make "doc2xml" to
recognize a XML template file addition to the one you saw and used before.
An new option -xXML_template_file is added. The XML template must has
<TEMPLATE> tag as a template root. <HDTXT> and <TLTXT> can be used to wrap
message around the generated XML document. It must be specified as XML
comment. For example, 
	<HDTXT>
	<!--<?XML version="1.0" ?><DocumentRoo>-->
	</HDTXT>	

<HEADER> is used to specified header, attributes can be specified as
attributes with <HEADER>. Five predefined attributes are reserved for the
Record Identifier (MATCH="nn"), alternate tag name (ALTTAG="nn"),
sub-element separator (SUB="nn"), element separator(SEP="nn"), record
terminator (TER="nn"). <RID> tag is used to tell where to extract
information from a record (or segment).

I updated the zip files except the one for SUN platform, you can get them
from 
	http://www.geocities.com/SiliconValley/Platform/4871/

I converted the "edi.tbl" template file to a valid XML file and it is call
"edi.tbl.xml". It can be view at 
	http://www.geocities.com/SiliconValley/Platform/4871/editblxml.html

Let me know how you think. I will update my web page when I have time.

Thanks and best regards,

Suli Ding

> ----------
> From: 	Petr Smolik[SMTP:petrs@brainsys.cz]
> Sent: 	Friday, November 13, 1998 7:34 AM
> To: 	suliding@yahoo.com
> Subject: 	Document to XML Convertor
> 
> 
> Greetings from Brno!
> I like your "Document to XML Convertor" activity. It is exactly
> what is needed. My question for you is: why the template is not
> an XML document? Why to design a new parser when we want to have
> only one parser - "the XML parser"?
> I'd be glad to hear from you and wish you lots of success.
> p.
> 
> Peter Smolik
> 
> 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov 16 10:13:11 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:34 2004
Subject: SAX Future
Message-ID: <000801be1149$1251ad20$7008e391@bra01wmhkay.bra01.icl.co.uk>

>Yes, but how do we accomplish this?  Do we invent a new package name
>for SAX 1.0.1 to avoid collision?


I suspect we have to - unless someone knows a better way. Given that parsers
include the SAX interface classes in their distribution, we don't really
want people to have several different definitions of the same interface on
their classpath.

Are there any other areas where you can get multiple implementations of the
same Java interface from different suppliers? If so, how do they solve the
version control problem? Or have we achieved a first?

There are other version control nasties lurking in the "helper" classes. For
example SUN's distribution includes a modified version of ParserFactory,
under the original package name and class name. (The modification is to load
SUN's parser if no other parser was specified). This means if you have
downloaded more than one SAX parser, it becomes somewhat random which
version of the SAX ParserFactory class gets loaded. You can't even write a
ParserFactoryFactory to influence the decision! However well-intentioned
SUN's actions, I think this should be banned - and we should design SAX
1.0.1 to make it unnecessary.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov 16 10:24:00 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:34 2004
Subject: Creation of XML documents
Message-ID: <000d01be114a$93204410$7008e391@bra01wmhkay.bra01.icl.co.uk>

Wester, JJ (ICT) <j.j.wester@kpn-telecom.nl> writes:

>I am involved in a similar project: we want to  replace the current
>inter-application communication techniques (RPC's, batch files etc) by XML
>document exchanges. This because XML makes the interfaces more flexible.
>We need methods and tools for the programmers who have to adapt old
>applications, or build new applications that communicate through XML to
>other applications.


I'm doing exactly this in a project at the moment. The different
applications that need to communicate all use different technology and the
right way to deliver the information varies in each case. We have a "data
interchange agent" for each application that encapsulates the data
interchange service (which uses XML over MSMQ) and delivers the data in a
way that the application finds natural. In general this is as a "business
object" rather than a DOM-level object (the agent knows the structure of the
business objects). For one application we deliver COM objects, for another
we deliver CORBA objects, and for a third we write the data to an SQL
database and activate triggers to process it. In all cases we hide the XML
structure from the application completely.

Contrary to the title of this thread, most of our effort has gone into
*receipt* of XML documents; creation of the documents is relatively easy.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Mon Nov 16 11:43:03 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:35 2004
Subject: SAX Future
Message-ID: <01BE115D.F9133990@grappa.ito.tu-darmstadt.de>

Michael Kay wrote:

> Are there any other areas where you can get multiple implementations of the
> same Java interface from different suppliers? If so, how do they solve the
> version control problem? Or have we achieved a first?

One that comes quickly to mind is JDBC, where each driver implements the same interfaces.  In JDBC 2.0, Sun has added methods to existing interfaces but has not (as far as I can tell) changed any 1.0 methods.  They have also added completely new interfaces and packages.

The version control problem is solved by two mechanisms:
* 100% backwards compatibility
* The ability of the application to query the version of the spec to which a given driver conforms.

The first point solves the problem of 1.0 applications working with 2.0 drivers.  Because 2.0 is a superset of 1.0, a 2.0 driver necessarily implements everything a 1.0 application uses.

The second point solves the problem of 2.0 applications working with 1.0 drivers.  The application queries the version of the spec supported by a driver and then only uses the functionality in the supported version.  If the application requires 2.0 functionality, it simply refuses to work with a 1.0 driver.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Mon Nov 16 12:04:49 1998
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:06:35 2004
Subject: Data attributes (was: Stylesheets considered limiting)
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
	 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
	 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
	 <3.0.5.32.19981112234611.0098ecd0@amati.techno.com>
	 <3.0.5.32.19981113155708.00a017c0@amati.techno.com> <3.0.5.32.19981115084926.008d6c60@amati.techno.com>
Message-ID: <36501509.2A75330C@mecomnet.de>

I make no claim that that the association is automatic. I simply point out
that namespaces (in particular, together with the element technique alluded to
in mr cowan's message) <EM>can</EM> be used to permit the same degree of
precision in descriptions. The syntax is different, and notation attributes
may well be a more compact expression, but the relations are the same.

W. Eliot Kimber wrote:
> 
> At 07:49 PM 11/14/98 +0100, james anderson wrote:
> >the situation described below is a case where a namespace prefix is well used
> >to ensure unambiguous naming. if one uses the notation or entity name as the
> >name prefix it awards the same expressive power as the implicit qualification
> >of data attributes.
> 
> I don't think it works though, because you don't know for sure that a given
> prefixed attribute is associated with a given entity--besides entity names
> are not, as far as I know, definable as namespace prefixes (that is, if a
> prefix happens to be spelled the same as an entity name, there's nothing
> that defines a necessary relationship between the two).

automatically no, permitted yes. (they are both 'Name's, aren't they?)
as the dtd writer, one would have to chose the names to the desired effect.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Patrice.Bonhomme at loria.fr  Mon Nov 16 14:29:07 1998
From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme)
Date: Mon Jun  7 17:06:35 2004
Subject: XPointer's sleeping ???
Message-ID: <199811161426.PAA24560@chimay.loria.fr>


Hi there,

I was wondering if there is something new about XPointer ?

Pat.

-- 
  ==============================================================
  bonhomme@loria.fr               |      Office : B.228
  http://www.loria.fr/~bonhomme   |      Phone  : 03 83 59 30 52
  --------------------------------------------------------------
   * Serveur Silfide  : http://www.loria.fr/projets/Silfide
   * Projet Aquarelle : http://aqua.inria.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 16 14:41:12 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:35 2004
Subject: Data attributes (was: Stylesheets considered limiting)
References: <3.0.5.32.19981111210459.009ba510@amati.techno.com>
	 <3.0.1.16.19981111210320.302765a0@pop3.demon.co.uk>
	 <3.0.5.32.19981110221631.008ec900@amati.techno.com>
	 <3.0.1.16.19981111021455.6f2f8962@pop3.demon.co.uk>
	 <3.0.5.32.19981111030746.009f0c10@pophost.fsc.fujitsu.com>
	 <3.0.1.16.19981110185833.09efb210@pop3.demon.co.uk>
	 <Pine.BSI.3.96r.981109231050.18125A-100000@shell1.interlog. com>
	 <3.0.32.19981103153315.00af8b30@pop.intergate.bc.ca>
	 <3.0.5.32.19981112075504.008d5b10@amati.techno.com>
	 <3.0.5.32.19981112234611.0098ecd0@amati.techno.com> <3.0.5.32.19981113155708.00a017c0@amati.techno.com>
Message-ID: <36503A09.7E0B00DC@locke.ccil.org>

W. Eliot Kimber wrote:

> Not necessarily. What if I have this situation:
> 
> <!NOTATION MyQuery PUBLIC "">
> <!NOTATION GIF PUBLIC "" >
> <!ENTITY mygif SYSTEM [ width="640" height="480" ]>

Presumably the above should include "NDATA GIF"?

> <Query notation="MyQuery" icon="mygif">find something</Query>

Supposing that MyQuery notation uses the attributes "table, select,
where" then your element above would map to:

  <Query notation="MyQuery" icon="mygif" GIF.width="640"
	GIF.height="480" MyQuery.table="this" MyQuery.select="that"
	MyQuery.where="foo=32">find something</Query>

Since notation names must be unique in a document, they can be used
uniquely to qualify data attribute names and make them into element
attributes (modulo the obvious trick of renaming attributes that
contain dots in their names).

Now of course if you have two different attributes of type ENTITY
referring to unparsed entities with the same notation, or two
different attributes of type NOTATION with the same value, or
one of each, then you need to extend the convention further.
Nevertheless, it *can* be done.  The effective attribute tree
gets flattened into an attribute space, with the tree information
stored in the attribute names.

> You can only specify one notation per element
> instance (which might be a design bug now that I think about it--I can
> thing of cases where the same element might be reasonably governed by
> different notations relevant to different processing domains).

Not true in XML anyway.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From amitr at abinfosys.com  Mon Nov 16 16:29:50 1998
From: amitr at abinfosys.com (Amit Rekhi)
Date: Mon Jun  7 17:06:35 2004
Subject: How will XML processors pass notation name, identifiers to applications?
Message-ID: <011301be114f$28b2fd20$0c01a8c0@vsnl.net.in>

Hello,
            After having read about NOTATIONS in XML from the spec. 
I had a ques. :-

 I have a sample xml file :-

<?xml version="1.0" ?>
<!DOCTYPE start-ele [
   <!NOTATION MyFormat SYSTEM "http://www.my.net/myformat.spc">
   <!ENTITY MyEnt SYSTEM "MyFormatData.ent" NDATA MyFormat>
   <!ELEMENT start-ele EMPTY>
   <!ATTLIST attr-for-notation ENTITY #REQUIRED>
]>
<start-ele attr-for-notation=MyEnt />

When a validating xml processor will start processing the above, it is 
supposed to pass

1) Notation Name (MyFormat in above case)
2) Notation System Identifier (http://www.my.net/myformat.spc)
3) Entity Name (MyEnt in the above case)
4) Entity System Identifier (MyFormatData.ent)

to the application (on behalf of which the xml processor is validating).


- How will the application know which are the elements for which
 the Notation name, Notation System ID,Entity Name,Entity System ID 
are to be taken from the XML processor?

- How will the XML processor pass the above 4 to the application?


Thanks in advance,

AMIT REKHI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981116/976a090b/attachment.htm
From amitr at abinfosys.com  Mon Nov 16 16:31:18 1998
From: amitr at abinfosys.com (Amit Rekhi)
Date: Mon Jun  7 17:06:35 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <00f101be114b$f8a73680$0c01a8c0@vsnl.net.in>

Ronald,

>The namespace URL does not signify anything at all.  It is not a directory,
schema file, >or anything else.  *All* it is is a unique identifier that
identifies the namespace.  The >prefix is a convenient shorthand for the
full URL, nothing more.

If the NameSpace URI is nothing more than a unique identifier then what kind
of  namespace processing do namespace aware XML processors do?
for eg. If I have a sample XML file :-

<?xml version="1.0"?>
<Root xmlns:ContentCheck="http://www.my.org/checkdirectory">
 <ContentCheck:Alpha>Test Data</ContentCheck:Alpha>
</Root>

 * How would the namespace aware XML processor react when it encounters
the statement
<Root xmlns:ContentCheck="http://www.my.org/checkdirectory"> and then
the element
<ContentCheck:Alpha>?

* Is the following processing flow for XML NameSpace
processing correct and sufficient ?

  1)The XML NS aware processor will check for ':' in the element names
      of XML file
  2) When it finds one (as is in <ContentCheck:Alpha>) it would look for
     the xmlns declaration for the prefix encountered
  3) On not finding the xmlns declaration it would flag an error
      then proceed to 5)
  4) On finding it do nothing and proceed to 5)
  5) The processor would go back to step 1) for the next element
      encountered

   * Am I right in saying that whatever the namespace URI signifies
      is for the application to know not for the XML processor?
      for eg. if I have an XML file

<xsl:stylesheet xmlns:xsl="http://www.w3c.org/TR/WD-xsl">
  <xsl:template> some text </xsl:template>
</xsl:stylesheet>

* Then it is for the application (XSL processor) to know what
"http://www.w3c.org/TR/WD-xsl "  stands  for, not the XML processor.
Am I right?

* It is upto the application , to validate
the element names prefixed with "xsl" against their definations ,
which are stored in the XSL DTD at  "http://www.w3c.org/TR/WD-xsl "
Am I correct?



                    Thanks for any help,


Regards,

AMIT


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tyler at infinet.com  Mon Nov 16 18:47:13 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:35 2004
Subject: SAX Future
References: <000801be1149$1251ad20$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <36507343.88D27817@infinet.com>

Michael Kay wrote:

> >Yes, but how do we accomplish this?  Do we invent a new package name
> >for SAX 1.0.1 to avoid collision?
>
> I suspect we have to - unless someone knows a better way. Given that parsers
> include the SAX interface classes in their distribution, we don't really
> want people to have several different definitions of the same interface on
> their classpath.
>
> Are there any other areas where you can get multiple implementations of the
> same Java interface from different suppliers? If so, how do they solve the
> version control problem? Or have we achieved a first?

I think the simple thing to do here is to simply extend the interfaces (this will
work in Java, but I am not so sure about other languages, particularly scripting
languages who have no concept of OOP in them) and add new functionality to the
new interfaces and deprecate the old interfaces.

Nevertheless, this approach is very sloppy IMHO (look at the development of the
AWT since JDK 1.0) even though it usually does get the job done.  But then again,
as far as I can tell, it will only get the job done in Java )-:

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


From ralph at fsc.fujitsu.com  Mon Nov 16 21:32:20 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:35 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
    Ballot
In-Reply-To: <3.0.5.32.19981114084806.00ef89b0@scripting.com>
References: <3.0.5.32.19981114102847.008a5e10@amati.techno.com>
Message-ID: <3.0.5.32.19981117042816.009c0ea0@pophost.fsc.fujitsu.com>

At 08:48 AM 11/14/98 -0800, Dave Winer wrote:
>What kind of applications would we use the Topic Map structures for? 
>
>It always helps me to understand this kind of stuff if I can understand a
>compelling application for it.
>

Topic Navigation Maps (TNMs) provide a means of structured navigation
through a body of related information. TNMs represent a generalization of
concepts such as indices, glossaries, thesauri, and tables of contents.
They follow a pattern of:

Subject
Subject definition
Links between related subjects

Link elements are used to create associations between related subjects;
metadata can be used to describe the relationships. 

TNMs also provide a means of expressing inter-relationships between bodies
of information. They are a key potential application area for
XML/XLink/XPointer. Or, said another way, TNMs represent a means for
applying XML/XLink/XPointer to KM.


Best regards,

Ralph E. Ferris
Fujitsu Software Corporation

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From xmldoubts at hotmail.com  Mon Nov 16 22:37:51 1998
From: xmldoubts at hotmail.com (Prashanth K. Salur)
Date: Mon Jun  7 17:06:35 2004
Subject: Infoseek announces XML search engine
Message-ID: <19981116223633.26734.qmail@hotmail.com>

Hi,

Is there any documentation available for this XML Search Engine. Can 
anyone give me the URL.

Thanks.

Regards,
SPK


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


From rexb at rbcomdesign.com  Mon Nov 16 22:52:22 1998
From: rexb at rbcomdesign.com (Rex Brooks)
Date: Mon Jun  7 17:06:36 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft	    Ballot
Message-ID: <199811162258.OAA18008@transbay.net>

Greetings,

I'm attaching a working proposal I made to the content development working
group of the vrml consortium, which I chaired until recently. As it turns
out, a recent post to our mailing list was made by Eric Pacquet, which I
will be forwarding to this list momentarily. Because the issue of Topic
Navigation Maps bears directly on this and includes the possibility of
forming a reflector if not a cross-standards working group aimed at
unifying the manageability of information resources on the web.

I also forwarded this paper to the enterprise wg list of the the VRML
Consortium which is changing its name to the Web3D Consortium in case you
didn't know. Daniel Lipkin, the chair of that group has been concerned with
xml integration, specifically with metadata concepts being included as a
node in VRML files. So, at the risk of seeming overly wide in my interests,
I think Eric's suggestions bear looking at.

Look for that post momentarily.

Ciao,
Rex Brooks

At  8:40 AM 11/15/98 -0600, W. Eliot Kimber wrote:
>At 08:48 AM 11/14/98 -0800, Dave Winer wrote:
>>What kind of applications would we use the Topic Map structures for?
>>
>>It always helps me to understand this kind of stuff if I can understand a
>>compelling application for it.
>
>A topic map consists, fundamentally, of two kinds of things: topics and
>associations. A topic is an object that represents a single rhetorical
>topic or subject. For example, "XML parser" might be one topic in a topic
>map about XML. A topic serves to associate the abstract idea of the topic
>with occurrences of that topic:
>
><topic xml:link="extended" role="topic" id="xml.parser">
><name>
><basename>XML Parser</basename>
></name>
><occur xml:link="locator" role="parser-instance"
>       href="http://www.jclark.com/xp"/>
><occur xml:link="locator" role="parser-instance"
>       href="http://www.microsoft.com/msxml/">
></topic>
>
>Notice that this serves to impose the semantic label "XML Parser" onto the
>occurrences addressed by the occur element.  Thus a topic can assert that a
>given object is an occurrence of some kind of thing.  This lets you
>construct a classfication or descriptive layer on top of existing data.
>The topics essentially represent opinions about the data.  Different topic
>map authors might express different opinions about the same data. Because
>the form the opinions are expressed in is standardized and consistent
>(topics), they can be reasonably compared to some degree.
>
>Because the topics are expressed formally as hyperlinks (here using Xlink,
>but also doable using HyTime), they are naturally navigable using whatever
>hyperlinking support you have lying about (e.g., HyBrick, PHyLIS, etc.).
>
>Associations relate topics to each other. To continue the XML topic map
>idea,  might have a relation "standard-interface-for" that I use to relate
>the topic "XML parser" to the topic "SAX":
>
><assoc role="standard-interface-for" xml:link="extended">
><assocrl role="parser" href="#id(xml.parser)" xml:link="locator"/>
><assocrl role="interface" href="#id(sax)" xml:link="locator"/>
></assoc>
>
>In many ways, this is like RDF: you can impose properties onto data objects
>and relate data objects together using typed links.  It may be that topic
>maps are one way to express RDF abstractions, I don't know (I don't know
>enough about RDF).  But while RDF seems to be designed primarily to support
>the addition or representation of metadata about objects, topic maps are
>designed for the creation of knowledge bases imposed on data of any type,
>and, in particular.  In any case, Topic Maps are not intended to compete
>with RDF--they are, in essence, different views of the same abstraction:
>objects with properties and relations among them.
>
>So what would you use topic maps for? I think one compelling use is as an
>annotative or descriptive layer over things like encyclopedias,
>dictionaries, databases, and the like. They might be used to enhance
>management information systems by providing a simple but rich and
>standardized way to capture analysis applied to existing data, such as
>market reports, sales numbers, etc.
>
>Topic maps can be a way to augment search and retrieval by providing a form
>of index over a larger, more amorphous body of data.
>
>Many documents can be turned into topic maps simply by labeling the
>existing components as topics. For example, you can think of a command
>reference document as a topic map where every command description is a topic.
>
>The reason for standardizing this concept is that it lets you build generic
>topic map engines that understand the specific properties of topics and
>associations and can therefore manage knowledge of those properties in a
>crisp and efficient way, making the information available to processing
>systems. It also allows the meaningful and automatic merging of topic maps
>because it's clear how the components of each relate to each other as objects.
>
>I'm not sure I've answered the question very well, but maybe I've provided
>enough of a taste for what topic maps do that applications will suggest
>themselves.  I've left out a number of important and interesting details in
>the discussion above, but I think I've conveyed the flavor.
>
>Cheers,
>
>Eliot
>--
><Address HyTime=bibloc>
>W. Eliot Kimber, Senior Consulting SGML Engineer
>ISOGEN International Corp.
>2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
>www.isogen.com
></Address>
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


-------------- next part --------------
Refining the VAN Database Concept

In the weeks leading up to my resignation from chair of the Content
Development Working Group, I worked with Mark Pflaging on some refinements
of the PROTO Repository, while attempting to obtain permission from Niclas
Olafsson for including his VRMLDoc Perl Program, or an adaptation of it.
There were several issues involved, beyond the surface efforts to get the
uploading capacity operational and develop a method for producing
documentation for every PROTO included in the repository.

Those work items were and remain necessary, but one of the tasks that most
needs to be done is to get the Database for the VAN started on the right
track, by which I mean the track it will inevitably follow. This is neither
intuitive from an artistic viewpoint, nor obvious from an business
application-centric software engineering standpoint. It is, in fact,
governed by the ISO, IEC conventions under development for the standardized
representations of information or data. My goal is to apply some
commonsensical adaptations of those developing standards to OUR developing
standard. (There is no doubt about it, I was born WAY too soon.)

One of the primary discussions we had early on in the CDWG was about what
we wanted the VAN to be. This discussion centered on the ease of use for
content creators who are primarily artists and new to VRML. These are the
fabled vast majority of users who will create the content necessary to
spread VRML to ubiquity.

However, until a much wider audience of vrml users is created, those
authors who will be populating the PROTO Repository of the VAN will NOT be
artists mostly but computer enthusiasts and artists who happen to be VRML
enthusiasts. That's an important distinction to make right now because the
people we want to encourage to take up VRML content creation are not going
to know how to search our repository on their own to find the components we
want them to find to make that content. And they are going to have be
taught VRML as well.

If you revisit the VAN Proposal, you will see that providing a means for
potential content creators to learn VRML and then move directly into using
the components in the VAN repositories is built in. However, it needs work,
real work in the writing and in the programming. I will certainly do what I
can.

Since the need of the Consortium right now is to get an operational
implementation of the VAN in place, I want to see to it that the ultimate
creation of the tools to make content creation EASIER goes on while that
simpler implementation is executed. Simpler in this case means simpler in
terms of programming and use by the computer literate, not for use by our
most important target audience. This needs to be understood so that we
don't end up "grandfathering" methodology that will be awkward and clumsy
to carry into the future.

What this preamble means is that the ultimate, "high-level front end" of
the PROTO Repository, and the other repositories of the VAN, has to be
easily searchable, where easily means easily useable by non-experts. One of
the most daunting elements of computer use by non-experts is the avalanche
of acronyms currently in use, so that is one of the first things we need to
avoid. Right after acronyms is jargon. What this means is that our VAN
needs to be searchable in plain language.

Unfortunately, plain language has almost nothing to do with database
design. So we have to take the database technology as we find it, and try
to make it work for our use, AND into the future of both our use and
database technology development. This need to have our database be
supported into the future is the primary reason why we decided we wanted a
Proprietary Database Solution specifically purchased or donated with the
future support written in. We chose Oracle at our face to face meeting at
SIGGRAPH98 in late July, and I specified Oracle 8i, with a Silver Support
Plan when asked for the specification by Platinum in Late October, at which
time it was scheduled for Release November 4, 1998.

So, that's where things stood when I resigned. In the week since, I have
thought about this quite a bit. Michael Wagner has suggested that this
would make a good Master's Thesis, and it might very well. I will certainly
be happy to pass my thoughts on to the academic folks he has suggested, and
to work with them, if that is appropriate for them, but I think this needs
to be pursued by the content group for the original purpose it was
conceived.

It does not need to be a top priority for showing in February at VRML99.
Parallel development cannot help but benefit us all, especially if we are
all working with "real" multimedia elements in a "real" operational
context--not just in an academic "modelled" context.

Our next wave of vrml content creators will mostly be coming out of the
business world of advertising and media and communications, though,
hopefully, some will come from academia as well. So our immediate needs,
beyond the most immediate need to demonstrate a proof of our concept at the
Symposium, is to make a useful, practical Resource Bank that can be put to
use next year in the world of commerce, which will pave the way for further
spread of VRML.

Of course, that can't be our only goal. We need to make sure VRML is
taught, and used for teaching.

This is all a win-win-win situation, if we can all work together. Let's not
leave anyone out, not Macintosh users, not Linux users, not SGI users, not
Solaris users,  not even NT users. And, that means, as near as I can manage
to make out, an XML-enabled, Object-Oriented, Web-Accessible, Interoperable
Java-based Database built on the principle of practical useability, and
that means searchability by non-experts.

As you may have reckoned by now, I actually have an operational plan to
propose, based on the work we have already done in the PROTO Repository
prototype of Mark Pflaging, and the latest developments in XML, and in our
own Enterprise Working Group, too. See what you think.

I propose creating a software program capable of taking information about
incoming PROTO submissions based on several top-level character data fields
in a table form similar to what Mark Pflaging has been using in the PROTO
Repository prototype, and using that information to set the classification
of the PROTO in the Repository. If possible, it would be desireable for the
program also to create some basic, standard, documentation of the PROTO
that could be optionally included in downloading the PROTO. Most of this is
already accomplished, but deserved mentioning nonetheless.

These fields would be first data parsed by the program and would be the
keys to placing the PROTO in the repository. These fields would be:

1. PROTO Name: This will be the name of the PROTO as written in VRML,
which we should encourage our contributors to prepare in the Recommended
Naming Convention form we have elucidated on our website in the example:

* PROTO TwoColorTable [field...
* TwoColorTablePROTO.wrl
* TwoColorTalbeExample.wrl
* TwoColorFurniturePackage.wrl#TwoColorTable

The common reference to this comprehensive PROTO naming convention is the
"Verbose Naming Convention".

2. Author's Name: Fairly self-explanatory, I assume.

3. Date of Original Submission/Date of Last Revision/Version Number

4. Type of VRML PROTO: This is a new item in the Database Schema, and will
have to be checked for conformance with recognized standards, but I
envision this field as having the following data:

		A. Primary (Simple?) Static Component: This means that the PROTO contains
no references to other objects, PROTOs, or multiple ImageTextures and has
no mechanism to change state. This would refer to mostly geometry objects
and sound objects, but possibly MovieTextures or MPEG-4 mediatypes. This
would also be the level of the VAN that would house elements not included
in the the UMEL.

		B. Secondary (Complex?) Static Component: This means that the PROTO
contains references to other objects, PROTOs and may contain multiple
ImageTextures, but has no mechanism to change state. This would refer to
compound objects, object collections or scengraphs

		C. Primary (Simple?) Dynamic Component (Behaviors): This means tha the
PROTO contains a single trigger that uses an EventIn and EventOut to send
values to a ROUTE and cause a change of state

		D. Secondary (Complex?) Dynamic Component (Behaviors): This means that
the PROTO contains multiple triggers and Events, ROUTEs and changes of
states.

5. Author's Descriptions: I propose that we discuss and arrive at a
standard set of Description Conventions similar in intent to the
Recommended Naming Convention, aimed at developing a secondary search, and
more advanced search mechanism based on the functions of the PROTOs, such
as Variable Transparency or Remote Object Detection as a kind of relational
refinement of the Type of VRML PROTO. This would probably have to be in a
second set of fields.

This set of fields or sets of fields if a second set is necessary for a
more advanced top level search of the database should be able to classify
all PROTOs that VRML currently allows. it does not specifically accommodate
multiple mediatypes or streaming of components, but shouldn't disallow
either.

This proposal does not purport to produce or replace the searchable
taxonomy of attributes we discussed earlier, and which is included (though
not completed) in the current PROTO Repository prototype. I believe that
this taxonomy of attributes can possibly be accomplished by applying the
principles that form the recent Proposed Standard for Topic Navigation
Maps. This is an approach we haven't pursued, but which appears to be
workable, and would certainly make our repository more interchangeable with
the rest of the ISO, IEC standards.

I believe that two concepts at work in XML should be considered as we go
forward in our attempt to develop the relational attribute taxonomy that
forms the heart of the Database, as opposed to this top-level sorting by
object-category deserve to be considered. These are Topics which will allow
groups of functionally similar PROTOs to be easily searched and retrieved,
and Groves, which similarly groups documents.

Please see this example of a Web-Based XML Application as an example of how
the SGML Tree Structure can work with the Grove concept and imagine how, as
an architectural model, VRML could be integrated within this structure,
and, more importantly, how this structure could be much more easily
depicted in VRML.

http://inf2.pira.co.uk/Grif/inria.html

My intent in this working proposal is to shape the database in the
direction of conformance with the ongoing development of XML and the recent
publication of Topic Navigation Map Proposed Standard.

This proposal does not, as far as I can tell, require any fundamental
changes in the work Mark Pflaging and Gavin Bell and Daniel Woods have done
so far.

The VRML Parser is an excellent tool and a great addition to the PROTO
Repository. I was going to suggest something like this, but I guess that
would be redundundant.

However, there are two items that I haven't specifically addressed in this
proposal.

First, is the necessity for deriving, requiring, or in some fashion, such
as employing something along the lines of Niclas Olafsson's VRMLDoc,
creating documentation for every PROTO that goes into the Repository. It
would be optional to download it.

Second is the necessity for creating an open source license with options
that can satisfy the spectrum of interests we know to exist amongst our
pool of potential contributors in a way that protects the interests the
Consortium and the CDWG from liability for the warrantability of the VAN's
contents, and protects the copyrights of the authors as the authors
require. As a co-chair of the VRML-IPR Task Group, I can only say that we
are working on it. We know that we will require a checkbox or radio button
that must be checked or marked off to signify acknowledgement of our
license requirements and disclaimers. This will occur on both the
submission of components and downloading components.

Well, that's it for right now. That's a lot more than enough for my poor
brain. It's full. Can't take no more.

Ciao,
Rex



From rexb at rbcomdesign.com  Mon Nov 16 22:55:53 1998
From: rexb at rbcomdesign.com (Rex Brooks)
Date: Mon Jun  7 17:06:36 2004
Subject: Web3D Consortium - Content-based - MPEG-7
Message-ID: <199811162301.PAA18110@transbay.net>

>
>To:eric.paquet@iit.nrc.ca, bob.crispen@boeing.com, dlipkin@us.oracle.com, 	
>thinktank@infomaniacs.com, enterprise@vrml.org, content@vrml.org, 	
>Don Brutzman <brutzman@nps.navy.mil>, vrml-mpeg4@vrml.org, 	        Rick Rafey
><rafey@arch.sel.sony.com>, Rob Glidden <robg@quadramix.com>, 	        Dick Puk
><puk@rbc.dec.com>, Steve Carson <carson@siggraph.org>, 	        Jeff Close
><close@halcyon.com>, Chris Marrin <chris@marrin.com>
>From:rexb@rbcomdesign.com (Rex Brooks)
>Subject:Re: Web3D Consortium - Content-based - MPEG-7
>X-Attachments::Atlantis:4838:VAN Database:
>
>At 11:12 AM 11/16/98 -0500, Eric Paquet wrote:
>>Dear Web3D Consortium members,
>>
>Nice timing, Eric. I have attached a paper proposing a refinement of the VAN
>Database which overlaps the area you describe. I am also considering sending
>it along to the XML-DEV list on which I have been lurking for the last couple
>of months. You certainly have my interest guaranteed.
>
>Do you think I should send this off with a request for someone from that list
>to work with us. Since this is being posted to Daniel Lipkin, I'd also like
>his thoughts on whether he would be interested in pursuing this connection.
>
>Thanks for such impeccable timing.
>
>Ciao,
>Rex
>
>>As you know, MPEG-7 is working on a standard set of descriptors
>>for multimedia content.  The WWW Consortium is also working on the
>>subject and there is a general consensus that it is becoming more and
>>more difficult to filter and retrieve pertinent information from the Web
>>
>>or any other multimedia source.  If the Web has to play a major role
>>as a 3D content provider in the future, those drawbacks have to
>>be overcome.
>>
>>During the past two years I have been working on that subject and I
>>would be very interested to go further in that direction: I am a member
>>of the Web3D Consortium and MPEG.  I would like to determine
>>if there are people interested by content-based access
>>of 3D databases.  Content based description includes metadata,
>>shape descriptors, colour descriptors, scale descriptors,
>>description schemes, etc.
>>
>>If a critical mass can be reached  I think we should put in place a
>>reflector and discuss all those issues including the creation of a
>>working group.
>>
>>I look forward to hearing from you.
>>
>>With best regards,
>>
>>Eric
>>-------
>>Dr Eric Paquet
>>Visual Information Technology
>>Institute for Information Technology
>>National Research Council
>>Ottawa (Ontario) Canada K1A 0R6
>>Telephone: (613) 991-5035
>>Facsimile: (613) 952-0215
>>E-mail: Eric.Paquet@iit.nrc.ca
>>http://www.vit.iit.nrc.ca/paquet
>



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Sung_Nguyen at datacard.com  Mon Nov 16 23:35:04 1998
From: Sung_Nguyen at datacard.com (Sung Nguyen)
Date: Mon Jun  7 17:06:36 2004
Subject: IE50 - XML Examples
Message-ID: <0015E44C.3096@datacard.com>

     Hi all:
     
     OK - I am using NT4.0 - why I have to include F:\SBN\include\NT50
     in order to run some examples (Microsoft C++ XML parser) ????
     
     If I don't include NT50 header files, I got following errors:
     
     F:\SBN\Include\shellapi.h(682) : error C2501: 'DWORD_PTR' : missing 
     decl-specifiers
     F:\SBN\Include\shellapi.h(682) : error C2239: unexpected token 
     '__stdcall' following declaration of 'DWORD_PTR'
     F:\SBN\Include\shellapi.h(682) : error C2059: syntax error : 
     '__stdcall'
     F:\SBN\Include\shellapi.h(683) : error C2501: 'DWORD_PTR' : missing 
     decl-specifiers
     F:\SBN\Include\shellapi.h(683) : error C2239: unexpected token 
     '__stdcall' following declaration of 'DWORD_PTR'
     F:\SBN\Include\shellapi.h(683) : error C2059: syntax error : 
     '__stdcall'
     F:\SBN\Include\prsht.h(356) : error C2501: 'INT_PTR' : missing 
     decl-specifiers
     F:\SBN\Include\prsht.h(356) : error C2239: unexpected token 
     '__stdcall' following declaration of 'INT_PTR'
     F:\SBN\Include\prsht.h(356) : error C2059: syntax error : '__stdcall'
     F:\SBN\Include\prsht.h(357) : error C2501: 'INT_PTR' : missing 
     decl-specifiers
     F:\SBN\Include\prsht.h(357) : error C2239: unexpected token 
     '__stdcall' following declaration of 'INT_PTR'
     F:\SBN\Include\prsht.h(357) : error C2059: syntax error : '__stdcall'
     Error executing cl.exe.
     
     If I included NT50 both headers and libs: I got the link error:
     
     Linking...
     F:\SBN\Lib\NT50\ole32.lib : fatal error LNK1106: invalid file or disk 
     full: cannot seek to 0x360de508
     Error executing link.exe.
     
     sample2.exe - 1 error(s), 0 warning(s)
     
     ------------------------------------------------------
     
     I don't know if someone out there can get these examples running???
     Please give me some hints, 
     
     Please, don't tell me that in order to run these Microsoft examples I 
     need to install NT5.0 beta.
     
     
     Regards and Thanks
     
     SeanNg
     
     
     ______________________________ Reply Separator 
     _________________________________
     Subject: RE: IE50 - XML Examples
     Author:  Chris Lovett <clovett@microsoft.com> at Internet
     Date:    11/7/98 8:34 PM
     
     
     You need the IE5 SDK which you can download from: 
     http://www.microsoft.com/gallery/samples/download/first.htm
     
     -----Original Message-----
     From: Sung_Nguyen@datacard.com [mailto:Sung_Nguyen@datacard.com] 
     Sent: Friday, November 06, 1998 6:10 PM
     To: Tyler Baker; Fernando Cabral
     Cc: Tim Bray; len bullard; xml-dev@ic.ac.uk; Barclay Rockwood 
     Subject: IE50 - XML Examples
     
     
     Hi all:
     
     I have trouble with linking the following example (downloaded from 
     MicroSoft site)
     This is the link error I got:
     
     "G:\mssdk\lib\ole32.lib : fatal error LNK1106: invalid file or disk 
     full: cannot seek to 0x35cb1cf1"
     
     The two files: "mshtml.h" msxml.h" I got from Internet SDK with IE4.0 
     I don't know if they are still compatible with IE5.0 and where I can 
     get new "mshtml.h" msxml.h" for IE5.0.
     
     Please point me the direction,
     
     Thanks a lot,
     
     SeanN
     
     --------------------------------------
     
     ////////////////////////////////////////////////////////////////////// 
     //////
     // Sample1.cxx: XML Object Model Sample 1 
     //-------------------------------------------------------------------- 
     ------
     // Copyright (c) 1998  Microsoft Corporation.  All Rights Reserved. 
     //
     // THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF 
     // ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO 
     // THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A 
     // PARTICULAR PURPOSE.
     //-------------------------------------------------------------------- 
     ------
     ////////////////////////////////////////////////////////////////////// 
     //////
     
     #include <windows.h>
     #include <windowsx.h>
     #include <stdlib.h>
     #include <stdio.h>
     #include <io.h>
     #include <hlink.h>
     #include <dispex.h>
     #include "mshtml.h"
     #include "msxml.h"
     #include <winnls.h>
     
     #define CHECKHR(x) hr = x; if (FAILED(hr)) goto Cleanup;
     #define SAFERELEASE(p) if (p) {(p)->Release(); p = NULL;} else ;
     
     ////////////////////////////////////////////////////////////////////// 
     //////
     // Synopsis: Create an IXMLElement of type t 
     ////////////////////////////////////////////////////////////////////// 
     //////
     IXMLElement* CreateXMLElement(IXMLDocument* pDoc, XMLELEM_TYPE t) 
     {
         IXMLElement* e;
         VARIANT type;
         type.vt = VT_I4;
         V_I4(&type) = t;
         VARIANT name;
     
         name.vt = VT_BSTR;
         V_BSTR(&name) = ::SysAllocString(L"ElementNode"); 
         HRESULT hr = pDoc->createElement(type, name, &e); 
         ::SysFreeString(V_BSTR(&name));
     
         return e;
     }
     
     ////////////////////////////////////////////////////////////////////// 
     //////
     // Synopsis: Create an XML Document from Scratch in memory 
     ////////////////////////////////////////////////////////////////////// 
     //////
     HRESULT MemDocument()
     {
         IXMLDocument           *pDoc = NULL; 
         IStream                *pStm = NULL; 
         IPersistStreamInit     *pPSI = NULL;
         IXMLElement            *enode = NULL, *el = NULL; 
         IXMLElement            *root = NULL; 
         LARGE_INTEGER li = {0, 0};
         HRESULT hr = S_OK;
         int i, j;
     
         // Create an empty XML document
         CHECKHR(CoCreateInstance(CLSID_XMLDocument, NULL, 
     CLSCTX_INPROC_SERVER,
                                     IID_IXMLDocument, (void**)&pDoc));
     
         // Query the IPersistStreamInit interface 
         CHECKHR(pDoc->QueryInterface(IID_IPersistStreamInit, (void 
     **)&pPSI));
     
         // Create an IStream
         CHECKHR(CreateStreamOnHGlobal(NULL, TRUE, &pStm)); 
         pStm->AddRef();
     
         //
         // Create an xml document with a root element 
         //
         ULONG ulWritten;
         CHECKHR(pStm->Write("<root/>", strlen("<root/>"), &ulWritten));
     
         // load the xml document
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL)); 
         CHECKHR(pPSI->Load(pStm));
     
         // get root element
         CHECKHR(pDoc->get_root(&root));
     
         //
         // Create an xml document in memory
         //
         for (i = 10; i > 0; i--)
         {
             enode = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT); 
             CHECKHR(root->addChild(enode, -1, -1));
     
             for (j = 10; j > 0; j--)
             {
                 el = CreateXMLElement(pDoc, XMLELEMTYPE_ELEMENT); 
                 CHECKHR(enode->addChild(el, -1, -1)); 
                 SAFERELEASE(el);
             }
             SAFERELEASE(enode);
         }
     
     
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL)); 
         CHECKHR(pPSI->Save(pStm, TRUE));
     
         //
         // Load the document from the in-memory stream 
         //
         CHECKHR(pStm->Seek(li, STREAM_SEEK_SET, NULL)); 
         CHECKHR(pPSI->Load(pStm));
     
     Cleanup:
     
         SAFERELEASE(root);
         SAFERELEASE(el);
         SAFERELEASE(enode);
         SAFERELEASE(pPSI);
         SAFERELEASE(pStm);
         SAFERELEASE(pDoc);
     
         return hr;
     }
     
     int _cdecl 
     main(int argc, char *argv[])
     {
         HRESULT hr = S_OK;
     
         CoInitialize(NULL);
     
         hr = MemDocument();
     
         CoUninitialize();
     
     
         return hr == 0 ? 0 : 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; 
(un)subscribe xml-dev
To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 17 00:29:51 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:36 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
	    Ballot
References: <3.0.5.32.19981114102847.008a5e10@amati.techno.com> <3.0.5.32.19981117042816.009c0ea0@pophost.fsc.fujitsu.com>
Message-ID: <3650C2D7.D3E@hiwaay.net>

Hi Ralph:

I am reasonably sure that one can implement topic map 
functionality in a set of relational tables and SQL queries, and then, 
as with RDF, export a compliant SGML/XML instance of that 
information.  Do you know of any reason why this would not 
work?

I ask because as Rex notes, some groups are attempting 
to build infrastructure for VRML communities that will be 
realized as a database.  While topic maps are attractive, 
I know of only two working implementations (it's been awhile so 
if there are more, great) and neither of these are in widespread 
use yet.  So to meet shortterm goals, a relational DB may 
be the best approach.  Still, it may be useful to ensure 
that topic maps can be produced to provide the information 
to those systems that can use topic maps.

Therefore the question:  if one is to implement relationally, 
what should one consider with an eye towards eventual use 
of topic maps?

len

>Ralph Ferris wrote:
>  
> Topic Navigation Maps (TNMs) provide a means of structured navigation
> through a body of related information. TNMs represent a generalization of
> concepts such as indices, glossaries, thesauri, and tables of contents.
> They follow a pattern of:
> 
> Subject
> Subject definition
> Links between related subjects
> 
> Link elements are used to create associations between related subjects;
> metadata can be used to describe the relationships.
> 
> TNMs also provide a means of expressing inter-relationships between bodies
> of information. They are a key potential application area for
> XML/XLink/XPointer. Or, said another way, TNMs represent a means for
> applying XML/XLink/XPointer to KM.
>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From amitr at abinfosys.com  Tue Nov 17 08:11:28 1998
From: amitr at abinfosys.com (Amit Rekhi)
Date: Mon Jun  7 17:06:36 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <072401be11fe$95347140$0c01a8c0@vsnl.net.in>

>So for now, namespace-aware processors should do nothing more than
>acknowledge the existence of the unique namespace.

This would mean that the NS processor would simply check for ":" in the
element name, and on finding it, it would try finding the
namespace declaration (of the kind xmlns="....") which matches prefix
found. That's it.
Am I right?


And the application on behalf of whom the XML NS processor is operating
can take care of validating the namespaces if that's what it intends to do.
Am I right?



AMIT



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Tue Nov 17 10:32:40 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:36 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <01BE121D.44C511F0@grappa.ito.tu-darmstadt.de>

Murray Altheim wrote:

> I don't believe that namespaces and validation are compatible, except in 
> the most trivial of cases. I've been making this statement for quite 
> awhile now, and have yet to see any response that proved otherwise. I tried
> to put together an XML-ized HTML 4.0 and CALS table DTD as an experiment, 
> but gave up in frustration. My understanding is that well-formedness is 
> generally all one would expect of a document that combined multiple 
> document types, as that is all the syntax currently allows. Some discussion
> suggests that a new, non-XML 1.0 schema mechanism may solve this, but for 
> now I wouldn't expect namespaced documents to be type-valid. 

I think this confuses two points: namespaces and combining DTDs.

Namespaces introduce a two-part naming system where previously there was a one-part naming system.  There is nothing inherently incompatible with this and validation.  The problem is trying to get current parsers (which were designed to use the one-part naming system) to validate documents that use namespaces.  This can be done, but is a hack -- as I stated in an earlier message, you must construct the DTD and the instance document using the same prefixes.  (Schema languages get around this by eliminating the DTD and introducing a mechanism to declare which namespace an element or attribute is in.  But, of course, current parsers do not know how to use schemas.)

Namespaces do not provide a mechanism for combining DTDs; they merely provide a way to differentiate element and attribute names if DTDs are combined.  Combining DTDs is currently a process that must be done by hand and is (unless ANY is widely used) almost certain to result in changes to those DTDs.  I've never looked at the CALS DTD, but my guess is that if you are trying to weave HTML into CALS tables and vice versa, this is, as you say, a very difficult task.  However, that is the fault of those DTDs, not namespaces.  (I also think that the trivial reuse of DTDs, such as me using your elements for an address or a mathematical equation in my DTD for a term paper is likely to be very common and very useful in the future.)

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Tue Nov 17 10:32:43 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:36 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <01BE121D.483CFAA0@grappa.ito.tu-darmstadt.de>

Amit Rekhi wrote:

> >So for now, namespace-aware processors should do nothing more than
> >acknowledge the existence of the unique namespace.
> 
> This would mean that the NS processor would simply check for ":" in the
> element name, and on finding it, it would try finding the
> namespace declaration (of the kind xmlns="....") which matches prefix
> found. That's it.
> Am I right?

The NS processor (parser) would then return the namespace URL and element name to the application.  As yet, there is no standard way to do this, but one suggestion for SAX-based applications is to use a parser filter to concatenate the namespace URL and the element name, separated by a caret (^).  (See http://www.ccil.org/~cowan/XML/ )

> And the application on behalf of whom the XML NS processor is operating
> can take care of validating the namespaces if that's what it intends to do.
> Am I right?

If by "validating the namespaces" you mean checking that the prefix used in the element or attribute name has been declared, it seems more appropriate that if the parser claims to be namespace-aware, it would perform this task.  Similarly, if the parser was a validating parser, it would also do any validation.

In general, though, the application's responsibility to know what to do with the element.  This is no different from the non-namespace case: if I define an element <foo>, your parser will have no idea what to do with it -- that is my application's job.  The only difference when namespaces are introduced is that elements and attributes now have two-part names instead of one-part names.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sroth at radsys.com  Tue Nov 17 15:49:30 1998
From: sroth at radsys.com (Roth, Scott)
Date: Mon Jun  7 17:06:36 2004
Subject: Question using MSXSL.exe
Message-ID: <5FAFB2A5D7B2D111ACEA0060972027CE1863A4@RADSYS_EXCH>

I am getting this error when I try to use it....


Error parsing document 'test.xml'
Exception: hr = 0x80070057


This happens on any XML file I use...can anybody help me???



Scott Roth

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Tue Nov 17 16:36:11 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:36 2004
Subject: How do XML NameSpace aware processors react to NS definations?
References: <00f101be114b$f8a73680$0c01a8c0@vsnl.net.in>
Message-ID: <3651A4A7.76E19B20@eng.sun.com>

Amit Rekhi wrote:
> 
> * Is the following processing flow for XML NameSpace
> processing correct and sufficient ?
> 
>   1)The XML NS aware processor will check for ':' in the element names
>       of XML file

Not sufficient -- it must preclude them in places like notation and
entity declarations, or PIs, and accept them in attribute names.
And what about ID, IDREF(S), ENTITY(IES), and NOTATION(S) attribute
values?

Basically, everywhere a name shows up in the XML grammar, processing
must change.  See the spec (http://www.w3.org/TR/WD-xml-names); the
section on conformance (6) covers all this.


>   2) When it finds one (as is in <ContentCheck:Alpha>) it would look for
>      the xmlns declaration for the prefix encountered

Similarly, <foo ContentCheck:Beta="Gamma"/> ... it makes things a
lot simpler to treat "xmlns:ContentCheck='...'" attributes just like
any others, except when hunting for NS declarations.


>   3) On not finding the xmlns declaration it would flag an error
>       then proceed to 5)

Note that the spec doesn't say what flagging an error means with
respect to conformance.  Is it fatal, for example? The lack of any
standard error handling in the spec will cause confusion.


>   4) On finding it do nothing and proceed to 5)

While correct, this isn't useful.  The application needs some way
to see the namespace associated with an element or an attribute,
and perhaps to list the namespaces available at a given node in an
XML graph.  The processor must report the namespace in some way.
 

>   5) The processor would go back to step 1) for the next element
>       encountered
> 
>    * Am I right in saying that whatever the namespace URI signifies
>       is for the application to know not for the XML processor?

It's hard to say without knowing what the difference between the
application and the processor is supposed to be.  And I'd say that
the application could realistically _tell_ the processor something
about what it means...


> * It is upto the application , to validate
> the element names prefixed with "xsl" against their definations ,
> which are stored in the XSL DTD at  "http://www.w3c.org/TR/WD-xsl "
> Am I correct?

Except that "xsl" isn't reserved, so you could have

    <foo:stylesheet xmlns:foo="http://www.w3c.org/TR/WD-xsl">
	...
    </foo:stylesheet>

and the application would be required to treat it as XSL, with
templates, process-children, 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Tue Nov 17 19:26:57 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:36 2004
Subject: SAX Future
References: <004001be0eee$466ce6e0$7008e391@bra01wmhkay.bra01.icl.co.uk> <13900.7613.719789.40250@localhost.localdomain>
Message-ID: <3651CCA2.7FBB2B53@eng.sun.com>

david@megginson.com wrote:
> 
>  > I think we can manage compatibility as follows:
>  > - We design 2.0 so that an application that conforms to SAX 1.0 also
>  > conforms to SAX 2.0
>  > - A standard wrapper round a SAX 1.0 parser should enable it to conform to
>  > SAX 2.0, providing null/default implementations of the new features where
>  > necessary. (E.g. the response to the question "are you a validating parser?"
>  > is "maybe").
> 
> Yes, but how do we accomplish this?  Do we invent a new package name
> for SAX 1.0.1 to avoid collision?

At least for Java, there are rules (in the Java Language Specification
as I recall) defining how to do compatible evolution of interfaces.

Defining a new package name isn't necessary, but it can make the API
look and act a lot cleaner.

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


From db at Eng.Sun.COM  Tue Nov 17 20:25:01 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:36 2004
Subject: SAX Future
References: <000801be1149$1251ad20$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <3651DA49.363A6E34@eng.sun.com>

Re the Java parts of that future:

Michael Kay wrote:
> 
> >Yes, but how do we accomplish this?  Do we invent a new package name
> >for SAX 1.0.1 to avoid collision?
> 
> I suspect we have to - unless someone knows a better way. Given that parsers
> include the SAX interface classes in their distribution, we don't really
> want people to have several different definitions of the same interface on
> their classpath.

As has been pointed out, strict binary compatibility for interfaces
ensures that this won't happen.

How to ensure that in the face of multiple distributions gets into
some legal issues.  Since SAX is in the public domain, it's got an
odd set of problems ... anyone can ship whatever they want and call it
SAX, in effect.  (We have no intention to do such a thing.  Sun is
very interested in "doing the right thing" here, working with David
Megginson and others.)

I think that part of the solution is to have conformance testing both
for SAX interfaces and for parsers implementing them.  Two parsers
should agree on what "fatal errors" are, for example, as well as the
data passed from the parser given specific input.  (Modulo the fact
that a block of text can be reported in one block or many, and so on.)


> There are other version control nasties lurking in the "helper" classes. For
> example SUN's distribution includes a modified version of ParserFactory,
> under the original package name and class name. (The modification is to load
> SUN's parser if no other parser was specified).

That is, a configuration error is transparently recovered from.

Anyone asking for a specific parser will always get it.  Anyone wanting
errors has countless ways to generate them ... ;-)

Of note:  This is the first comment we've received on this clearly
documented
change!  The method "Create[s] a new SAX parser using the org.xml.sax.parser
system property", per spec.


>	 However well-intentioned
> SUN's actions, I think this should be banned - and we should design SAX
> 1.0.1 to make it unnecessary.

I'm curious how you'd design an updated SAX to not have the capability of
such a configuration error.  Get rid of the notion of a default system
configuration, pushing the problem up to application developers?  That is
the approach some other systems take.

Re "banning" ... without some conformance testing, what would that mean?

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


From ralph at fsc.fujitsu.com  Tue Nov 17 23:00:15 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:36 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
     Ballot
In-Reply-To: <3650C2D7.D3E@hiwaay.net>
References: <3.0.5.32.19981114102847.008a5e10@amati.techno.com>
 <3.0.5.32.19981117042816.009c0ea0@pophost.fsc.fujitsu.com>
Message-ID: <3.0.5.32.19981118055522.009b2b50@pophost.fsc.fujitsu.com>

At 06:27 PM 11/16/98 -0600, you wrote:
>Hi Ralph:
>
>I am reasonably sure that one can implement topic map 
>functionality in a set of relational tables and SQL queries, and then, 
>as with RDF, export a compliant SGML/XML instance of that 
>information.  Do you know of any reason why this would not 
>work?

I'm reluctant to make a definitive statement here. To a first
approximation, the approach your suggesting appears workable. Whether it
will work efficiently for complex TNMs - and TNMs can become very complex -
is another matter. As I believe you're aware, the path to TNMs has been a
long, and at times circuitous, one. The draft that now exists might have
been titled "Topic Navigation Maps - Or, the Return of Vannevar Bush",
intended as it is to capture complex inter-relationships, i.e., "real"
hypertext. How well that maps into relational, or any other type of
database, is something we'll have to find out.

>
>Therefore the question:  if one is to implement relationally, 
>what should one consider with an eye towards eventual use 
>of topic maps?

Areas that seem to me to bare particular scruntity include the approaches
to defining topic naming in 5.2.1 Topic Link Architectural Form:

- e.g., "A topic may have zero or more occurrences. If a topic has no
occurrences, it must have at least one name. If a topic has one occurrence
or more, it may have no name." 

- And 5.2.3 Topic Occurrence, 

e.g., "The occurrence role name of an occur element (or, when its
occurrence role name is not specified, the generic identifier of this occur
element) declares the limited contexts within which a topic has the
occurrences referenced by this occur element." 

I suspect that accounting for the "may" and "or" aspects in these
statements could get interesting. Likewise, supporting scoping as defined. 

I have to emphasize though that these are only impressions; I make no claim
to having explored the topic as yet in any detail from the point of view
you're proposing. 



Best regards,

Ralph E. Ferris
Fujitsu Software Corporation  

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cbullard at hiwaay.net  Wed Nov 18 00:40:12 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:36 2004
Subject: Worthy Reading
References: <3.0.5.32.19981114102847.008a5e10@amati.techno.com>
	 <3.0.5.32.19981117042816.009c0ea0@pophost.fsc.fujitsu.com> <3.0.5.32.19981118055522.009b2b50@pophost.fsc.fujitsu.com>
Message-ID: <365216E9.2828@hiwaay.net>

This article was posted to the VRML list today.  It makes reference to
the need for VRML and XML integration.  As this is a proposal for the 
VRML NG (next generation) and the concepts of a prototype based system 
are similar to concepts discussed here, I think it may be worthy 
reading for the XML language and implementation designers.  

http://neuchatel.artemedia.ch/balaguer/vrml99/vrml99-final-p2.html

With the recent events concerning the XML Chrome application, the 
work in architectures, the need to demonstrate that extensibility 
need not always be the prelude to balkanization, approaches such as 
this paper describe should be of some interest.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 18 01:08:22 1998
From: clovett at microsoft.com (Chris Lovett)
Date: Mon Jun  7 17:06:36 2004
Subject: Question using MSXSL.exe
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C08744091@RED-MSG-56>

The technology preview msxsl.exe does not run under the IE5 Beta.  Use the
XSL support built into IE5 instead.

-----Original Message-----
From: Roth, Scott [mailto:sroth@radsys.com]
Sent: Tuesday, November 17, 1998 7:50 AM
To: xml-dev@ic.ac.uk
Subject: Question using MSXSL.exe


I am getting this error when I try to use it....


Error parsing document 'test.xml'
Exception: hr = 0x80070057


This happens on any XML file I use...can anybody help me???



Scott Roth

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From xmldoubts at hotmail.com  Wed Nov 18 01:20:30 1998
From: xmldoubts at hotmail.com (Prashanth K. Salur)
Date: Mon Jun  7 17:06:37 2004
Subject: DOM
Message-ID: <19981118011909.15337.qmail@hotmail.com>

Hi all,
Is a white space(#text) also considered as a node in a DOM. How to 
ignore the white space?

Thanks

Regards
SPK

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


From tyler at infinet.com  Wed Nov 18 03:46:16 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:37 2004
Subject: DOM
References: <19981118011909.15337.qmail@hotmail.com>
Message-ID: <36524365.8BBBEAFB@infinet.com>

"Prashanth K. Salur" wrote:

> Hi all,
> Is a white space(#text) also considered as a node in a DOM. How to
> ignore the white space?
>
> Thanks
>
> Regards
> SPK

One thing you can do to normalize an element's character data and all of its
child element character data is to call Element.normalize().

This is the simplest thing to do here.  The only problem with this approach is
that when you call normalize on an element all sub-elements are also normalized.
I suppose you could write your own utility routine which would effectively do the
same thing as normalize, though only on the immediate character data of the
selected element, so you may want to do that.

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


From amitr at abinfosys.com  Wed Nov 18 05:40:33 1998
From: amitr at abinfosys.com (Amit Rekhi)
Date: Mon Jun  7 17:06:37 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <003501be12a3$f837d390$0c01a8c0@vsnl.net.in>

>If by "validating the namespaces" you mean checking that the prefix used in
the >element or attribute name has been declared, it seems more appropriate
that if the >parser claims to be namespace-aware, it would perform this
task.  Similarly, if the >parser was a validating parser, it would also do
any validation.

Assuming that the parser is a validating NS aware parser,
I was wondering what other validations could the parser perform.

* It would be difficult for the parser to validate the content model,
attributes of all the prefixed names against their definations in the DTD
since the Namespace URI only signifies a unique identifier, nothing more.So
validating prefixed names in the way given above would be difficult.
Am I right?
Then what other validations are left which are relevant to namespaces?

                                                Thanks ,


Regards,

AMIT




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Wed Nov 18 10:10:48 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:37 2004
Subject: SAX Future
Message-ID: <000801be12db$139c70f0$7008e391@bra01wmhkay.bra01.icl.co.uk>

>> There are other version control nasties lurking in the "helper" classes.
For
>> example SUN's distribution includes a modified version of ParserFactory,
>
>That is, a configuration error is transparently recovered from.
>
In SUN's position I think I might well have done the same thing, as it
clearly makes their product easier to install and get working. However, as a
user, I don't find it very useful to have several identically-named
ParserFactory classes on my class path, and to worry about which one has
been loaded! SUN circumvented a deficiency in SAX, and we ought to fix it at
source.

The ParserFactory in SAX plays the same role as the Driver Manager in ODBC;
we can't have every driver come with its own driver manager, we must have a
single driver manager which is rich enough in capability to configure any
drivers you might want to install.

In my view a good ParserFactory will have a user interface allowing you to
install a parser and specify your choice of default; it will have persistent
storage to remember what parsers are installed and which one is the current
default; and it will have an API allowing you to discover which parsers are
installed, to ask questions about them, and to select one that meets your
requirements (using a friendly name chosen when it was installed). In turn
each Parser needs to come with installation-time code that registers the
parser with the ParserFactory, giving the user the option to make it the
default one.

(All this applies equally, of course, to DOM implementations).

I tried to meet some of these requirements with the ParserManager in SAXON.
It's not ideal: the user interface is to edit a properties file; the process
of registering a new parser is entirely manual; it doesn't allow you to
register attributes, e.g. which parsers are validating and which aren't. But
I think it's a start, and I've certainly found it useful in my own work.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jjc at jclark.com  Wed Nov 18 10:16:34 1998
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:06:37 2004
Subject: XML test cases updated
Message-ID: <36529D06.40B9E159@jclark.com>

I've updated my collection of test cases at

 ftp://ftp.jclark.com/pub/xml/xmltest.zip

to deal with some bugs and arguable cases.

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


From Lloyd.Rutledge at cwi.nl  Wed Nov 18 10:22:59 1998
From: Lloyd.Rutledge at cwi.nl (Lloyd Rutledge)
Date: Mon Jun  7 17:06:37 2004
Subject: XPointer's sleeping ??? 
In-Reply-To: Your message of "Mon, 16 Nov 1998 15:26:44 MET."
             <199811161426.PAA24560@chimay.loria.fr> 
Message-ID: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>


On Mon, Nov 16 1998 Patrice Bonhomme wrote:
> I was wondering if there is something new about XPointer ?

Most definitely.  The W3C XML Linking Working Group was recently
formed and is discussing XLink and XPointer.  An XML Linking Interest
Group is expected to form shortly to have more public (within W3C)
discussion of the two formats.  For more information take a look
at the working group page at

  http://www.w3.org/XML/Group/Linking.html

It includes a link to the XPointer requirements document, updated
last Thursday.

-Lloyd

--
Lloyd Rutledge                                         vox: +31 20 592 41 27
CWI (Centrum voor Wiskunde en Informatica)             fax: +31 20 592 41 99
Kruislaan 413,  NL-1098 SJ Amsterdam, The Netherlands  net: lloyd@cwi.nl
P.O. Box 94079, NL-1090 GB Amsterdam, The Netherlands  http://www.cwi.nl/~lloyd

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Wed Nov 18 12:25:29 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:37 2004
Subject: XPointer's sleeping ??? 
In-Reply-To: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
References: <199811161426.PAA24560@chimay.loria.fr>
	<UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
Message-ID: <13906.47931.562005.126248@localhost.localdomain>

Lloyd Rutledge writes:

 > For more information take a look at the working group page at
 > 
 >   http://www.w3.org/XML/Group/Linking.html
 > 
 > It includes a link to the XPointer requirements document, updated
 > last Thursday.

Unfortunately, this is not a publicly-accessible document -- it
requires a member password or access from an authorised IP address
(everything in the XML/Group hierarchy is member-confidential).

There's not a lot that the public can read right now, but the Activity 
Statement will at least give an idea of what's going on and a summary
of each XML WG:

  http://www.w3.org/XML/Activity.html


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 18 13:26:09 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:37 2004
Subject: XPointer's sleeping ??? 
In-Reply-To: <13906.47931.562005.126248@localhost.localdomain>
References: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
 <199811161426.PAA24560@chimay.loria.fr>
 <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
Message-ID: <199811181325.IAA25670@hesketh.com>

At 07:23 AM 11/18/98 -0500, david@megginson.com wrote:
>Unfortunately, this is not a publicly-accessible document -- it
>requires a member password or access from an authorised IP address
>(everything in the XML/Group hierarchy is member-confidential).
>
>There's not a lot that the public can read right now, but the Activity 
>Statement will at least give an idea of what's going on and a summary
>of each XML WG:
>
>  http://www.w3.org/XML/Activity.html

Hmmm... Eight months without a new draft, and everything past the draft is
member confidential.  You know, if the W3C had a more open process, we
might be a lot closer to the XLink standard we've all been craving...

Back to the peanut gallery...


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 18 15:25:36 1998
From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme)
Date: Mon Jun  7 17:06:37 2004
Subject: SAX drivers bug ... or feature !
Message-ID: <199811181523.QAA06423@chimay.loria.fr>


Hi,

I think there is a little problem with AttributeList implementation within 
some of the SAX drivers (i have tested the following code with my SXP SAX 
driver, the XML4J SAX driver and the AELFRED SAX driver. We are all giving the 
same results (gosh...).

This code should write the size of each AttributeList that has been read by 
the parser when it reached the end of the Document. But it always prints the 
size of the last AtributeList found.

Bug or feature ?

Pat.

/*
 * @(#)       saxbug.java
 * 
 * Copyright  1998 (C) PATRICE BONHOMME
 *            UMR LORIA (Universities of Nancy, CNRS & INRIA)
 *
 */

import org.xml.sax.*;
import org.xml.sax.helpers.*;

import java.util.Vector;

/**
 * SAX demonstration.
 * 
 *
 * @version   
 * @author    Patrice Bonhomme, bonhomme@loria.fr
 */

public class saxbug
  extends org.xml.sax.HandlerBase
{
  public static void main (String args[] ) throws Exception
  {
    saxbug demo = new saxbug();
    Parser parser = null;
    
    try {
      
      // try to create a SAX parser
      parser = ParserFactory.makeParser();
      System.out.println(parser);
      parser.setDocumentHandler(demo);
      
    } catch (ClassNotFoundException e) {
      System.err.println("SAX parser class cannot be loaded.");
      System.exit(1);
    } catch (IllegalAccessException e) {
      System.err.println("SAX parser class does not have a zero-argument 
constructor.");
      System.exit(1);
    } catch (InstantiationException e) {
      System.err.println("SAX parser class cannot be instantiated.");
      System.exit(1);
    }
    
    for (int i = 0; i < args.length; i++) {
      System.out.println("parsing => " + args[i]);
      try {
	parser.parse(args[i]);
      } catch(Exception e) {
	System.out.println(e.getMessage());
      }
    }
  }

  //  HandlerBase methods overriding

  public void setDocumentLocator (Locator locator)
  {
  }
  
  Vector attrs;

  /**
   * @see org.xml.sax.DocumentHandler#startDocument
   */
  public void startDocument ()
  {
    attrs = new Vector();
  }

  
  /**
   * Print the size of each AttributeList within the Vector <code>attrs</code>
   * @see org.xml.sax.DocumentHandler#endDocument
   */
  public void endDocument ()
  {
    int j = 0;
    
    for (java.util.Enumeration e = attrs.elements(); e.hasMoreElements();j++) {
      AttributeList attlist = (AttributeList)e.nextElement();
      System.out.println("size of attlist(" + j +")=" + 
((AttributeList)attlist).getLength());
    }
  }
  
  
  /**
   * Add the AttributeList to the Vector <code>attrs</code>.
   *
   * @see org.xml.sax.DocumentHandler#startElement
   */
  public void startElement (String name, AttributeList attributes)
  {
    System.out.println("Start element: " + name + " size of attlist=" + 
attributes.getLength());
    attrs.addElement(attributes);
  }


  /**
   * @see org.xml.sax.DocumentHandler#endElement
   */
  public void endElement (String name)
  {
  }


  /**
   * @see org.xml.sax.DocumentHandler#characters
   */
  public void characters (char ch[], int start, int length)
  {
  }


  /**
   * @see org.xml.sax.DocumentHandler#ignorableWhitespace
   */
  public void ignorableWhitespace (char ch[], int start, int length)
  {
  }


  /**
   * @see org.xml.sax.DocumentHandler#processingInstruction
   */
  public void processingInstruction (String target, String data)
  {
  }
  
  // DTD Handler implementation

  /**
   * @see org.xml.sax.DTDHandler#unparsedEntityDecl
   */
  public void unparsedEntityDecl (String name,
                                  String publicId,
                                  String systemId,
                                  String notationName)
  {
  }

}

// EOF


-- 
  ==============================================================
  bonhomme@loria.fr               |      Office : B.228
  http://www.loria.fr/~bonhomme   |      Phone  : 03 83 59 30 52
  --------------------------------------------------------------
   * Serveur Silfide  : http://www.loria.fr/projets/Silfide
   * Projet Aquarelle : http://aqua.inria.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Wed Nov 18 15:46:27 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:37 2004
Subject: SAX drivers bug ... or feature !
Message-ID: <01BE1312.528F3A90@grappa.ito.tu-darmstadt.de>

Patrice Bonhomme wrote:

> I think there is a little problem with AttributeList implementation 
within
> some of the SAX drivers (i have tested the following code with my SXP SAX 
> driver, the XML4J SAX driver and the AELFRED SAX driver. We are all 
giving the
> same results (gosh...).
>
> This code should write the size of each AttributeList that has been read 
by
> the parser when it reached the end of the Document. But it always prints 
the
> size of the last AtributeList found.
>
> [code snipped]

It is a good bet that all the parsers are doing what I have done in my 
parsers: used a single instance of an AttributeList object, then cleared it 
and reused it for each call to startElement.  Thus, all the references in 
your Vector point to the same object.

This is specifically allowed by the SAX spec.  The documentation for 
AttributeList states, "The instance provided will return valid results only 
during the scope of the startElement invocation (to save it for future use, 
the application must make a copy: the AttributeListImpl helper class 
provides a convenient constructor for doing so)."

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Wed Nov 18 16:01:38 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:37 2004
Subject: SAX drivers bug ... or feature !
Message-ID: <008f01be1309$d1f21810$7008e391@bra01wmhkay.bra01.icl.co.uk>


>I think there is a little problem with AttributeList implementation within
>some of the SAX ...
>Bug or feature ?
>
Feature. See
http://www.megginson.com/SAX/javadoc/org.xml.sax.AttributeList.html#_top_ I
quote:

The instance [of AttributeList] provided will return valid results only
during the scope of the startElement invocation (to save it for future use,
the application must make a copy: the AttributeListImpl helper class
provides a convenient constructor for doing so).

This statement should probably be in the specification of the startElement()
method rather than the AttributeList class, so you can be excused for
missing it, but it's there.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cbullard at hiwaay.net  Wed Nov 18 18:38:40 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:37 2004
Subject: XPointer's sleeping ???
References: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
	 <199811161426.PAA24560@chimay.loria.fr>
	 <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl> <199811181325.IAA25670@hesketh.com>
Message-ID: <3653137E.1FD0@hiwaay.net>

Simon St.Laurent wrote:
> 
> Hmmm... Eight months without a new draft, and everything past the draft is
> member confidential.  You know, if the W3C had a more open process, we
> might be a lot closer to the XLink standard we've all been craving...

Wasn't SAX designed on an open list?  Hasn't the schema been designed 
on an open list? Most of the work XLink is based on is public.  All of
the information 
you need to create open hypermedia linking is in the HyTime documents.  
All of the XML syntax data is open.  Take the XLink draft, clean it up, 
put new names on it, then publish it and implement it.  If you can 
do that faster, you may get a better result.  If you decide to 
adapt XLink when it is released, you probably won't too far off 
the mark.

If a closed society doesn't provide results, open one.  So far, VRML 
is doing pretty well with that approach.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 18 18:40:44 1998
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:06:37 2004
Subject: XML over HTTP
Message-ID: <365314A4.24609C12@mecomnet.de>

Greetings;

I have a simple question.

What are people doing when they read xml 'over the wire'?. It would appear
that the logical structure of an xml document (to wit
  [1] document ::= prolog element Misc*
) is at odds with the protocol specified for things like a http put operation.
For which a response from the recipient cannot come until after the operation
is performed. As a consequence of which, the input socket remain open (being a
two-way stream in order to write the response) after the object has been read.
In which case EOF is not a useful hint that the document is complete.

The same problem will appliy to connections which are kept alive for extended communications.

We could well assert a specific document structure, - for example prescribing
miscellaneous content after the document element, but i'm wondering what the
general W3 intent was.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Wed Nov 18 19:45:17 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:37 2004
Subject: XPointer's sleeping ???
In-Reply-To: <3653137E.1FD0@hiwaay.net>
References: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
 <199811161426.PAA24560@chimay.loria.fr>
 <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
 <199811181325.IAA25670@hesketh.com>
Message-ID: <199811181944.OAA31630@hesketh.com>

At 12:35 PM 11/18/98 -0600, len bullard wrote:
>Simon St.Laurent wrote:
>> Hmmm... Eight months without a new draft, and everything past the draft is
>> member confidential.  You know, if the W3C had a more open process, we
>> might be a lot closer to the XLink standard we've all been craving...
>
>Wasn't SAX designed on an open list?  Hasn't the schema been designed 
>on an open list?

Uh, yes to both.  And in case you've forgotten, I was the fool who started
XSchema - and passed it on to another editor (for whose work I'm extremely
grateful) when I was too busy to complete it rather than sitting on it for
months.

> Most of the work XLink is based on is public.  All of
>the information 
>you need to create open hypermedia linking is in the HyTime documents.  
>All of the XML syntax data is open.  Take the XLink draft, clean it up, 
>put new names on it, then publish it and implement it.  If you can 
>do that faster, you may get a better result.  If you decide to 
>adapt XLink when it is released, you probably won't too far off 
>the mark.

Two things.

First, I am implementing the XLink draft (in Java - open source) as it
stands, with help from volunteers.  See
http://www.simonstl.com/projects/xlinkfilter/ for details.  The
implementation will be updated as the W3C drafts emerge.

Second, I've already been told to "go to your room" once on this list (yes,
that's a quote!) when I proposed work (XSchema) that overlapped with the
W3C's proposed work.  As it turned out, XSchema is done and the W3C's
schema work is only getting started.  On the other hand, I'd have to be
totally demented to pick up the WD, make my own changes, and publish it.
The W3C's work on XLink is in progress, however slow, and the W3C has an
effective monopoly on this work.  No one is going to implement _my_ draft
of their work except me.  As a result, it makes much more sense to wait for
the W3C (however difficult waiting may be) and implement what I can so that
my work is eventually compatible.

>If a closed society doesn't provide results, open one.  So far, VRML 
>is doing pretty well with that approach.

If I could open the W3C process, or start a new parallel open process, I
would.  Since neither of those things is possible (the W3C won't likely
open its doors if I just plain ask, and a parallel effort would have no
credibility), I'm pretty much left to suggest what might have been _if_ the
W3C had an open process instead of this closed process -> open standards
approach they take now.

So - back to the peanut gallery.




Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 18 21:27:26 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:37 2004
Subject: SAX drivers bug ... or feature !
In-Reply-To: <199811181523.QAA06423@chimay.loria.fr>
References: <199811181523.QAA06423@chimay.loria.fr>
Message-ID: <13907.15037.18263.923498@localhost.localdomain>

Patrice Bonhomme writes:

 > I think there is a little problem with AttributeList implementation
 > within some of the SAX drivers (i have tested the following code
 > with my SXP SAX driver, the XML4J SAX driver and the AELFRED SAX
 > driver. We are all giving the same results (gosh...).
 > 
 > This code should write the size of each AttributeList that has been
 > read by the parser when it reached the end of the Document. But it
 > always prints the size of the last AtributeList found.

There is a bug in your sample code:

 >   /**
 >    * Add the AttributeList to the Vector <code>attrs</code>.
 >    *
 >    * @see org.xml.sax.DocumentHandler#startElement
 >    */
 >   public void startElement (String name, AttributeList attributes)
 >   {
 >     System.out.println("Start element: " + name + " size of attlist=" + 
 > attributes.getLength());
 >     attrs.addElement(attributes);
 >   }

it should be

   /**
    * Add the AttributeList to the Vector <code>attrs</code>.
    *
    * @see org.xml.sax.DocumentHandler#startElement
    */
   public void startElement (String name, AttributeList attributes)
   {
     System.out.println("Start element: " + name + " size of attlist=" + 
                        attributes.getLength());
     attrs.addElement(new AttributeListImpl(attributes));
   }


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 01:15:52 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ???
References: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
	 <199811161426.PAA24560@chimay.loria.fr>
	 <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
	 <199811181325.IAA25670@hesketh.com> <199811181944.OAA31630@hesketh.com>
Message-ID: <365370B9.45A6@hiwaay.net>

Simon St.Laurent wrote:
> 
> Uh, yes to both.  And in case you've forgotten, I was the fool who started
> XSchema - and passed it on to another editor (for whose work I'm extremely
> grateful) when I was too busy to complete it rather than sitting on it for
> months.

And you have results to show for it.  I'm willing to bet real money that
everyone 
who worked on that learned a lot.  Whatever the W3C comes up with, they
have 
to show it to a much smarter audience, right?  Well done.  Hardly
foolish. 

> Second, I've already been told to "go to your room" once on this list (yes,
> that's a quote!) when I proposed work (XSchema) that overlapped with the
> W3C's proposed work. 

Unless they start coming to your house and threatening violence, 
take that sort of email as the bullying it is and understand it 
is done by a bully.  Give this some thought:  what is soooo 
important or sooo brilliant it has to be hidden while being 
designed.  I can see that for the initial design while trying to 
work out what goes in which orifice, but after that, no.  It is 
what it looks like:  exclusive collusion.  Think:  Xlink and 
Xpointer are based on work that has been going on for at least a 
decade now.  How much CAN it change?  One of the results of HyTime 
was the knowledge that links come down to a handful of types.  
I am mystified by the delays but they probably have more to 
do with resources, coordination, the usual sloth of design by 
committee and consensus, not malevolent: just entropy.

> If I could open the W3C process, or start a new parallel open process, I
> would.  

You did once and it was successful.  It has been done by others just as 
successfully.   What you may not get is the support of the dues paying 
members of the W3C.  OTOH, you might.  It isn't a monolith and shouldn't 
be considered such.   If by open process, you get a better design, what 
competitor would use an inferior one just to stay even with the other 
competitive members of the club.  Nope.  Doesn't work that way.  Now 
will some talk your design down?  Sure.  Will they take your ideas and
use 
them?  Certainly.  That is the risk of openness and the reason some 
work in cloisters.   It is called Fear.  OTOH, if they do and the 
overall system improves, you did your job even if they got the credit.  

There is no end to what you can get done if you don't mind who gets 
the credit.  OTOH, cash and carry takes no credit.

>  Since neither of those things is possible (the W3C won't likely
> open its doors if I just plain ask, and a parallel effort would have no
> credibility), I'm pretty much left to suggest what might have been _if_ the
> W3C had an open process instead of this closed process -> open standards
> approach they take now.

The W3C can't.  Their members forbid it.  They fear it.

Let the Dead Software Society go to their cave and read from ancient 
books of lore.  Running code doesn't care.  That was the lesson 
I learned watching the birth of the web.

I will slither back under the rock now.  Next week, I have to 
convince a certain nubile to eat a green apple. :-)

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


From db at Eng.Sun.COM  Thu Nov 19 02:37:20 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:38 2004
Subject: XML over HTTP
References: <365314A4.24609C12@mecomnet.de>
Message-ID: <3653840F.89A706C1@Eng.Sun.COM>

james anderson wrote:
> 
> Greetings;
> 
> I have a simple question.
> 
> What are people doing when they read xml 'over the wire'?. It would appear
> that the logical structure of an xml document (to wit
>   [1] document ::= prolog element Misc*
> ) is at odds with the protocol specified for things like a http put operation.

No it isn't; HTTP handles NNNN bytes of data, the XML document is MMMM 
characters long, one only needs to know the number of bytes to exchange
the stuff over HTTP.  It's encoded in HTTP message header fields, or else
implicitly by the end (EOF) of the particular message.


> For which a response from the recipient cannot come until after the operation
> is performed. As a consequence of which, the input socket remain open (being a
> two-way stream in order to write the response) after the object has been read.
> In which case EOF is not a useful hint that the document is complete.

This is the same problem anyone writing POST/PUT code deals with.  The
client must use one of several techniques to terminate the request entity;
the server uses one of them to terminate the response entity.  (This is
"entity" in the MIME sense, not the XML sense.)

	- Do a half-close after sending ... use shutdown() to tweak the
	  TCP code to report EOF on that side of the connection.

	- Content-Length: NNNN ... that is, recipient reads NNNN octets
	  and that signifies end of entity.  Both close() afterwards.

	- Content-Length: NNNN ... like above, but using one of the
	  various keepalive HTTP flavors (preferably HTTP/1.1 not
	  the earlier version).  So, no close() afterwards, normally.

	- HTTP/1.1 supports chunked data, delivered in counted chunks.
	  This is like setting Content-Length, except that you can
	  avoid buffering the whole entity (e.g. a 4 Mbyte file) by
	  sending it chunk-at-a-time.

HTTP is like _any_ normal RPC protocol in that it doesn't permit response
data to be sent before the request has been read in.  There are atomicity
issues. 

- Dave



> The same problem will appliy to connections which are kept alive for
> extended communications.
> 
> We could well assert a specific document structure, - for example prescribing
> miscellaneous content after the document element, but i'm wondering what the
> general W3 intent was.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Thu Nov 19 03:24:52 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ???
In-Reply-To: <365370B9.45A6@hiwaay.net>
References: <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
 <199811161426.PAA24560@chimay.loria.fr>
 <UTC199811181021.LAA22643.lloyd@klipper.cwi.nl>
 <199811181325.IAA25670@hesketh.com>
 <199811181944.OAA31630@hesketh.com>
Message-ID: <199811190324.WAA05656@hesketh.com>

At 07:13 PM 11/18/98 -0600, Len Bullard wrote:

[much excellent stuff regarding open processes]

When I start a discussion with you, I'm almost always cranky at best,
infuriated with you at worst.  Once it develops, I'm amazed and
enlightened.  In this case, I don't think I'll set up my own XLink draft
(though we'll see what happens as my implementation progresses - there are
a lot of holes to patch), but it's good to remember that such things are
indeed possible.

Great stuff, Len.  I owe you even more beer than I did before. Someday...


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 06:26:15 1998
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun  7 17:06:38 2004
Subject: SQL DTD
References: <003501be12a3$f837d390$0c01a8c0@vsnl.net.in>
Message-ID: <3653B9E2.47E87B36@allette.com.au>

Has anyone done anything in the way of creating a DTD capable of representing
simple SQL commands? We need to pass commands to an interface layer between an
application and a database, but for their own purposes the writers of the
interface layer would prefer to interpret XML over SQL.


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


From rbourret at ito.tu-darmstadt.de  Thu Nov 19 09:23:52 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:38 2004
Subject: How do XML NameSpace aware processors react to NS definations?
Message-ID: <01BE13A5.F9353D20@grappa.ito.tu-darmstadt.de>

Amit Rekhi wrote:

> Ronald Bourret wrote:
>
> > If by "validating the namespaces" you mean checking that the prefix 
used in
> > the element or attribute name has been declared, it seems more 
appropriate
> > that if the parser claims to be namespace-aware, it would perform this
> > task.  Similarly, if the parser was a validating parser, it would also 
do any validation.
>
> Assuming that the parser is a validating NS aware parser,
> I was wondering what other validations could the parser perform.
>
> * It would be difficult for the parser to validate the content model,
> attributes of all the prefixed names against their definations in the DTD
> since the Namespace URI only signifies a unique identifier, nothing 
more.So
> validating prefixed names in the way given above would be difficult.
> Am I right?
> Then what other validations are left which are relevant to namespaces?

You are confusing two different things: validation (meaning to enforce the 
validity constraints in the XML spec) and enforcing the namespace 
constraints in the namespaces spec.  These are completely independent of 
each other.

The program that processes the namespaces must enforce the namespace 
constraints.  Generally, this will be the parser or a layer (such as John 
Cowan's namespace parser filter) built on top of the parser. In the case of 
a namespace-aware, validating parser, the parser enforces this.

The program that performs validation enforces the validity constraints. 
 This is usually a validating parser.  This program gets the information to 
validate against from the DTD.  It gets the DTD from the DOCTYPE statement; 
the DOCTYPE statement always points to the DTD, regardless of whether 
namespaces are used or not.  As you point out, the parser does not get the 
DTD from the namespace URI; the namespace URI is just a unique identifier 
and does not necessarily point to anything.

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Thu Nov 19 12:10:59 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:38 2004
Subject: Announce: Topic Map Standard out for Final Committee Draft
      Ballot
In-Reply-To: <3.0.5.32.19981118055522.009b2b50@pophost.fsc.fujitsu.com>
References: <3650C2D7.D3E@hiwaay.net>
 <3.0.5.32.19981114102847.008a5e10@amati.techno.com>
 <3.0.5.32.19981117042816.009c0ea0@pophost.fsc.fujitsu.com>
Message-ID: <3.0.5.32.19981119060611.008d9100@amati.techno.com>

At 05:55 AM 11/18/98 -0500, Ralph Ferris wrote:
>At 06:27 PM 11/16/98 -0600, you wrote:
>>Hi Ralph:
>>
>>I am reasonably sure that one can implement topic map 
>>functionality in a set of relational tables and SQL queries, and then, 
>>as with RDF, export a compliant SGML/XML instance of that 
>>information.  Do you know of any reason why this would not 
>>work?
>
>I'm reluctant to make a definitive statement here. To a first
>approximation, the approach your suggesting appears workable. 

It's important to not focus overmuch on the syntax of things like Topic
Maps (or RDF or HyTime or Xlink or ...).  If you think of topic maps in
terms of their fundamental abstract data model, then it becomes clear that
a relational or object database implementation must be sensical as long as
it reflects the same data model.  

As part of the topic map design work, I developed an EXPRESS-G model of the
topic map data model.  Once we've verified this model (it was just my own
effort done largely to help me understand the topic map design), I plan to
post it somewhere (probably the HyTime User's Group site, www.hytime.org).
Taken as input, any compentent database wonk could use that model, plus the
prose of the topic map standard, to implement a provably conforming topic
map processor. The data of that processor could always be interchanged
using Topic Map syntax.

As for implementatons, I have also developed a sample Topic Map using Xlink
and displayable with Fujitsu's HyBrick tool, which implements Xlink
sufficient to allow navigation of the links. I built a style sheet that
takes advantage of Topic Map-specific relations to present information
about the topics and relations over and above there base linkish nature.
This I will also post once I've verified that it's reasonably correct.  I
also plan to implement a simple Topic Map engine on top of PHyLIS once I
complete my current reimplementation effort (hopefully by the end of the
year).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Thu Nov 19 14:52:37 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:38 2004
Subject: Attr nodes in DOM
Message-ID: <01BE13D3.F587D6A0@grappa.ito.tu-darmstadt.de>

How do I get all the attributes of an element in DOM?

The third paragraph in the Element interface states that, "...since the 
Element interface inherits from Node, the generic Node interface method 
getAttributes may be used to retrieve the set of all attributes for an 
element."  Unfortunately, the description of the Node interface lists no 
such method.

Is this what the attributes property of Node is for?

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 quake.net  Thu Nov 19 15:00:32 1998
From: donpark at quake.net (Don Park)
Date: Mon Jun  7 17:06:38 2004
Subject: Attr nodes in DOM
Message-ID: <007b01be13cd$573495c0$2ee044c6@arcot-main>

>Is this what the attributes property of Node is for?


yes.  'attributes' maps to 'getAttributes'.

Perhaps there is a need for non-scripting language version of the DOM
spec...

Don



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From daveh at persimmon.co.uk  Thu Nov 19 15:03:30 1998
From: daveh at persimmon.co.uk (Dave Halls)
Date: Mon Jun  7 17:06:38 2004
Subject: Attr nodes in DOM
References: <01BE13D3.F587D6A0@grappa.ito.tu-darmstadt.de>
Message-ID: <36543318.A5E7033F@persimmon.co.uk>

Ronald Bourret wrote:

> How do I get all the attributes of an element in DOM?
>
> The third paragraph in the Element interface states that, "...since the
> Element interface inherits from Node, the generic Node interface method
> getAttributes may be used to retrieve the set of all attributes for an
> element."  Unfortunately, the description of the Node interface lists no
> such method.
>
> Is this what the attributes property of Node is for?
>
>

from the javadoc (with DOMSDK anyway)...



Interface org.w3c.dom.Node

getAttributes

public NamedNodeMap getAttributes()

       A NamedNodeMap containing the attributes of this node (if it is an
Element) or null otherwise.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Thu Nov 19 15:18:35 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ??? 
Message-ID: <3.0.32.19981118212239.01b81b90@pop.intergate.bc.ca>

At 08:26 AM 11/18/98 -0500, Simon St.Laurent wrote:
>Hmmm... Eight months without a new draft, and everything past the draft is
>member confidential.  You know, if the W3C had a more open process, we
>might be a lot closer to the XLink standard we've all been craving...

To be fair, note that XML itself, and in fact all W3C standards,
have member-confidential drafts.  XLink, like XML, will have
lots of invited experts on board.  

Also, not speaking for any group, I expect few suprises from 
XLink - there have been more-or-less stable specs for over a 
year and no real evidence that they don't work as intended. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 15:18:42 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ???
Message-ID: <3.0.32.19981118213225.00de51d8@pop.intergate.bc.ca>

At 02:47 PM 11/18/98 -0500, Simon St.Laurent wrote:
>If I could open the W3C process, or start a new parallel open process, I
>would.  Since neither of those things is possible (the W3C won't likely
>open its doors ...

There is some reasoning behind the rather-less-open
W3c process.  After the IETF HTML process went off the rails, some
people who were there (I wasn't) felt that one of the reasons was
that open processes in areas where there are all sorts of billion-dollar
bets on the table are highly fragile in the face of attack-trained
marketing departments.  The great virtue of the W3C process is that
the marketeers are more or less muzzled until consensus has been
achieved.  Which is pretty important.  In fact, engineers from
companies who are mortal enemies can demonstrably carve out 
mutually beneficial progress if they are allowed to do so out
of the marketing spotlight.

If someone came forward with a proposal that made the W3C process
more transparent while keeping the debate, as much as possible, on
technical grounds, that would be a clear step forward and I suspect
would be welcomed by everyone. 

At a deeper level, there is also a really tough issue at work here.
Simply put, smaller committees can get *way* more work done than can
larger ones.   On the other hand, such groups are by definition
much less open/democratic than larger ones.  So we have two virtues,
get-some-standards-built-quick vs make-sure-we-get-all-the-input,
which are in direct competition with each other.  Not an
easy nut to crack. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 15:39:08 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:38 2004
Subject: DTD for RFC's
Message-ID: <3.0.32.19981119074235.00e34df8@pop.intergate.bc.ca>

Is there a DTD around for making IETF RFC's?  Even better, some code
to produce the deadly-boring RFC text output from a tagged version?
  -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 15:41:40 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ???
In-Reply-To: <3.0.32.19981118213225.00de51d8@pop.intergate.bc.ca>
Message-ID: <199811191540.KAA13507@hesketh.com>

At 07:21 AM 11/19/98 -0800, Tim Bray wrote:
>There is some reasoning behind the rather-less-open
>W3c process.  After the IETF HTML process went off the rails, some
>people who were there (I wasn't) felt that one of the reasons was
>that open processes in areas where there are all sorts of billion-dollar
>bets on the table are highly fragile in the face of attack-trained
>marketing departments.  The great virtue of the W3C process is that
>the marketeers are more or less muzzled until consensus has been
>achieved.  Which is pretty important.  In fact, engineers from
>companies who are mortal enemies can demonstrably carve out 
>mutually beneficial progress if they are allowed to do so out
>of the marketing spotlight.
>
>If someone came forward with a proposal that made the W3C process
>more transparent while keeping the debate, as much as possible, on
>technical grounds, that would be a clear step forward and I suspect
>would be welcomed by everyone. 

I've spent far too much of the last two days pondering this issue, and the
only thing I can come up with (besides opening the W3C to the entire planet
minus the sales and marketing staffs of the world) is the W3C taking a less
exclusive approach to its work.  The W3C already accepts notes from members
that are the work of non-W3C processes - in other words, maybe six people
from one company and some guy from another company were talking at a bar,
and a proposal came out... without all the overhead and approval processes
of the W3C.  

Maybe if the W3C were more willing to accept Notes from non-members (or if
a member would sponsor Notes on such a basis), 'open-process'
specifications could be developed outside the W3C, in the bright light, and
submitted if and when they're finished.  This would allow projects like SAX
and XSchema to germinate, have a target for completion, and potentially get
some kind of official 'acceptance' from the primary WWW standards keepers.
The W3C could still accept, reject, and set up WGs, but at least there
would be an open door.

This would put the responsibility for process management on those foolhardy
enough to initiate such projects (which devour time, believe me) while
still keeping such avenues open. SAX and XSchema have definitely had an
impact on W3C-sanctioned projects, but more official acceptance might
encourage further potentially useful projects. It might also make it easier
for engineers from W3C members to contribute to such projects without
feeling like they're undercutting their more official responsibilities to
the W3C.

In the case of XLink, this is probably too late; nonetheless, it might not
be such a bad idea to open discussion on that to a larger field, since
there are plenty of non-invited experts with HyTime experience.  I don't
think there's much marketing to be done there, either.  (Come get your
fresh links!  Fifty cents a piece, mustard, ketchup, sauerkraut, and chili
extra!  Onions are free with purchase of a link and condiments!)

>At a deeper level, there is also a really tough issue at work here.
>Simply put, smaller committees can get *way* more work done than can
>larger ones.   On the other hand, such groups are by definition
>much less open/democratic than larger ones.  So we have two virtues,
>get-some-standards-built-quick vs make-sure-we-get-all-the-input,
>which are in direct competition with each other.  Not an
>easy nut to crack. -Tim

The mythical man-month still lives...

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 15:59:24 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ???
In-Reply-To: <199811191540.KAA13507@hesketh.com>
References: <3.0.32.19981118213225.00de51d8@pop.intergate.bc.ca>
	<199811191540.KAA13507@hesketh.com>
Message-ID: <13908.15897.59730.62122@localhost.localdomain>

Simon St.Laurent writes:

 > I've spent far too much of the last two days pondering this issue,
 > and the only thing I can come up with (besides opening the W3C to
 > the entire planet minus the sales and marketing staffs of the
 > world) is the W3C taking a less exclusive approach to its work.
 > The W3C already accepts notes from members that are the work of
 > non-W3C processes - in other words, maybe six people from one
 > company and some guy from another company were talking at a bar,
 > and a proposal came out... without all the overhead and approval
 > processes of the W3C.

Yes, but the status of W3C NOTE has essentially no value -- it's just
the W3C's way of saying "we've put this up at our web site and posted
a response, but that doesn't mean that we really have anything to do
with it."  Some marketing departments like to exploit any confusion in
the general public and talk about notes as if they were standards, but
woe to the programmer who bases anything on a NOTE (as with those who
based implementations on the late and unlamented XML-Data NOTE).

As far as I understand things, there is no automatic process for W3C
NOTES -- a W3C staffer posts a response and then they just sit there
forever, unless some Activity happens to want to use them as input
(but they can use non-W3C material like XSchema as input as well).
The only advantage is that NOTEs sit around in a high-visibility
location, and presumably, the visibility is a perk that the members
will want to keep for themselves.

That said, there are a lot of small, $5K/year W3C members -- it
shouldn't be hard to find at least one of them who would be willing to
put something like XSchema forward as a NOTE, if someone else is
willing to deal with all of the bureaucratic overhead and paperwork.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 16:43:22 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:38 2004
Subject: XPointer's sleeping ???
In-Reply-To: <13908.15897.59730.62122@localhost.localdomain>
References: <199811191540.KAA13507@hesketh.com>
 <3.0.32.19981118213225.00de51d8@pop.intergate.bc.ca>
 <199811191540.KAA13507@hesketh.com>
Message-ID: <199811191643.LAA14329@hesketh.com>

At 10:57 AM 11/19/98 -0500, David Megginson wrote:
>Yes, but the status of W3C NOTE has essentially no value -- it's just
>the W3C's way of saying "we've put this up at our web site and posted
>a response, but that doesn't mean that we really have anything to do
>with it."  Some marketing departments like to exploit any confusion in
>the general public and talk about notes as if they were standards, but
>woe to the programmer who bases anything on a NOTE (as with those who
>based implementations on the late and unlamented XML-Data NOTE).
>
>As far as I understand things, there is no automatic process for W3C
>NOTES -- a W3C staffer posts a response and then they just sit there
>forever, unless some Activity happens to want to use them as input
>(but they can use non-W3C material like XSchema as input as well).
>The only advantage is that NOTEs sit around in a high-visibility
>location, and presumably, the visibility is a perk that the members
>will want to keep for themselves.

I understand that NOTEs have no official value; however, they do serve a
number of purposes.

1) They are part of a central repository of NOTEs, in a location where
people looking for standards information regularly look.

2) The W3C at least reads and acknowledges the things formally. They may
read XSchema and SAX, but those of us outside the 'member-only zone' don't
hear about it, except through occasional question emails.  (Hint: make
mistakes in your spec that have no real effect except to make things sound
really weird.  If W3C XML WG members start writing you to ask about them,
your spec may be getting a good thorough read.  No, that's not what I
recommend, but it's about where I'm at.)

3) They're about as close to a billboard announcing a spec as exists.

>
>That said, there are a lot of small, $5K/year W3C members -- it
>shouldn't be hard to find at least one of them who would be willing to
>put something like XSchema forward as a NOTE, if someone else is
>willing to deal with all of the bureaucratic overhead and paperwork.

Reaching the small $5K/year members to ask them to post something they
didn't write is a political and bureaucratic task in itself, and pretty
much a barrier to all but the most dedicated (or wealthy.  $15,000, and
you're in for three years.)

I realize that asking the W3C to accept Notes from non-members imposes
costs on them and produces neglible benefits (beyond ego gratification) to
those of us who would like to see a more open process.  Unfortunately, the
options appear to be:

1) Do nothing.  Forget about open process unless it starts growing like
open source is right now. (Probably what the members want most.)

2) Do something small.  Allow submissions by non-members  At least the open
process people won't complain as much, and you can prettify your image by
claiming to be 'the standard body that listens', or something.

3) Do something huge.  Open up the process, and get over the members-only
approach that's so inimical to the open source and open process movements
that are starting to make a dent.  Reconsider the standards process, and
find independent money rather than relying on the contributions of
companies that use your name for PR while selectively applying
'recommendations'.

I'd love to see #3 happen; unfortunately, going to Cambridge and shouting
"Dr. Berners-Lee, tear down this wall!" isn't going to do very much.  #2
seems like a more likely possibility, however minor it may be.

I think this discussion's moved beyond the realm of XML-Dev, though it
concerns many XML-Dev projects.  Is there a better place for
revolutionaries, counter-revolutionaries, and moderates to discuss these
issues?  Can't say I know of a forum.



Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From creitzel at mediaone.net  Thu Nov 19 17:30:43 1998
From: creitzel at mediaone.net (Charles Reitzel)
Date: Mon Jun  7 17:06:39 2004
Subject: Topic Maps on SQL
Message-ID: <199811191730.MAA13298@chmls05.mediaone.net>

len bullard <cbullard@hiwaay.net> wrote:
>I am reasonably sure that one can implement topic map 
>functionality in a set of relational tables and SQL queries, 
>and then, as with RDF, export a compliant SGML/XML instance 
>of that information.  Do you know of any reason why this 
>would not work?

SQL is ok but not great at associations.  It is terriffic when the
attributes/columns are relatively fixed but falters when the
attribute/column set is variable within the membership of a single
association set.  Put another way, topic maps seem inherently Smalltalk-like
and not very C++-like.

If you are searching a document base, you want to be able to find any
document or element with an attribute "X" containing "Y".  You don't want to
have to find all the tables that contain column "X" and emit the appropriate
SQL for each (possible, but probably inefficient).  More importantly, you
don't want to be either: a) creating new tables all the time or b) adding
new columns to your existing tables.

I have often found it useful to create SQL meta-tables for code lookups,
domain validation, etc.  These work great, but are inefficient for large
data sets.  I have created pure association tables in the past, but have
never been happy with them.  If you were insistent, the tables might look
like this:

CREATE TABLE ASSOC_LINK
(
    ID_A        NUMBER(8)   NOT NULL,   /* SEQUENCE# OF THING A */
    ID_B        NUMBER(8)   NOT NULL,   /* SEQUENCE# OF THING B */
    ASSOC_TYP   VARCHAR(8)  NOT NULL,   /* APP DEPENDENT CODE THAT */
                                        /* WILL TELL YOU WHAT THINGS */
                                        /* A AND B ARE AND WHAT */
                                        /* TABLES THE ACTUAL DATA */
                                        /* ARE IN. MIGHT ALSO */
                                        /* INCLUDE DIRECTION OF */
                                        /* ASSOCATION, ETC. */
    /* YOUR ASSOCATION DATA HERE */
    /* ... */
);

/* META-DATA! */
CREATE TABLE ASSOC_TYPE
(
   ASSOC_TYP    VARCHAR(8)  NOT NULL,   /* PK, LOOK UP FROM ASSOC_LINK */
   DESCRIP      VARCHAR(240) NOT NULL,
   TBL_A        VARCHAR(60) NOT NULL,
   COL_A        VARCHAR(60) NOT NULL,
   TBL_B        VARCHAR(60) NOT NULL,
   COL_B        VARCHAR(60) NOT NULL,
   DIRECTION    VARCHAR(4)  NOT NULL,
   CLASS_ID     VARCHAR(1000),          /* Used to instantiate handler! */
   REMARKS      VARCHAR(2000)
);

CREATE TABLE ASSOC_KEYWORD
(
   KW_ID        NUMBER(8)   NOT NULL,   /* SEQUENCE# USED BY ASSOC_LINK */
   KEYWORD      VARCHAR(60) NOT NULL,   /* DATA! */
   DESCRIP      VARCHAR(240)
);

CREATE TABLE ASSOC_XPTR
(
   XP_ID        NUMBER(8)   NOT NULL,   /* SEQUENCE# USED BY ASSOC_LINK */
   XP_TYP       VARCHAR(8)  NOT NULL,   /* IDREF, XPointer expression, etc. */
   HREF         VARCHAR(1000) NOT NULL,
   DESCRIP      VARCHAR(240)
);

CREATE TABLE ASSOC_TOPIC
(
   TOPIC_ID     NUMBER(8)   NOT NULL,   /* SEQUENCE# USED BY ASSOC_LINK */
   DESCRIP      VARCHAR(240)
);

With these tables you can:
        Create linear lists of topics, keywords and pointers,
        Associate pointers with topics,
        Associate keywords with topics,
        Associate keywords with pointers,
        Associate keywords with keywords (synonyms, antonyms, etc.)

This isn't too bad, but it assumes that you use generated sequence numbers
as a primary/unique key to each table participating in the association.
What you are really doing here is implementing the network data model on a
relational database.  If you need a network data model use one.  It will run
much faster and your code will be much simpler.  Raima and Platinum are two
vendors of hybrid relational/network databases that I know of.  Raima does a
decent job of making set association look like a SQL join.

With both database models, however, you still have the column problem,
though.  I doubt the above would be sufficient for real world document
repositories. 

Regards,
Charles Reitzel
creitzel@mediaone.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 19 18:06:36 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:39 2004
Subject: XPointer's sleeping ???
Message-ID: <004f01be13e7$a3a8e2c0$26f96d8c@NT.JELLIFFE.COM.AU>


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

>I'd love to see #3 happen; unfortunately, going to Cambridge and shouting
>"Dr. Berners-Lee, tear down this wall!" isn't going to do very much.  #2
>seems like a more likely possibility, however minor it may be.

One comment I have (no flames) is that a good idea does not die.  10 years
ago
no-one would have dreamed we would all be using block-mode terminals (HTML),
reading articles about "WYSIWYG is Dead", and using garbage-collecting
programming 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Fri Nov 20 09:16:51 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:39 2004
Subject: XPointer's sleeping ???
Message-ID: <005901be1465$e90d06b0$7008e391@bra01wmhkay.bra01.icl.co.uk>

>At a deeper level, there is also a really tough issue at work here.
>Simply put, smaller committees can get *way* more work done than can
>larger ones...

Actually, it's the other way round. Large committees produce large
standards, and large
standards never get implemented. Small committees are good because they do
*less* work.

W3C is actually the latest in a long line of industry standards consortia
(ECMA, X/Open, OMG ...) which was set up to be small and fast, which
produced really good output in its first couple of years, and which then
gradually became big and slow. I personally don't believe secrecy will solve
this problem, because it is caused more by the tendency for the scope and
complexity of the work program to grow exponentially, than by the
decision-making process. I don't know what will solve the problem: my guess
is that W3C will eventually go the same way as the others, and yet another
new small/fast consortium will step in to take over the reins. I already
hear the initial soundings...

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From donpark at quake.net  Fri Nov 20 19:05:23 1998
From: donpark at quake.net (Don Park)
Date: Mon Jun  7 17:06:39 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <00aa01be14b8$ce365dc0$2ee044c6@arcot-main>

A simple question: does any of the new schema proposals have something
equivalent to internal subset?  In other words, does DCD, XML Schema,
XML-Data, RDF Schema, or XSchema allow schema to be placed in the same file
as data?

Don Park
Docuverse



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jarle.stabell at dokpro.uio.no  Fri Nov 20 20:03:12 1998
From: jarle.stabell at dokpro.uio.no (Jarle Stabell)
Date: Mon Jun  7 17:06:39 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <3.0.32.19981120210257.007f5270@hedvig.uio.no>

Don Park wrote:

>A simple question: does any of the new schema proposals have something
>equivalent to internal subset?  In other words, does DCD, XML Schema,
>XML-Data, RDF Schema, or XSchema allow schema to be placed in the same file
>as data?

Related question:

Instead of an internal subset B of an external schema A, would it be better
to make B also an external schema "inheriting" A in some way?
(For general processing, stylesheets, reuse etc, wouldn't it be best to
externalize as much as possible?)


Cheers,

Jarle Stabell
Digital Logikk AS


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From donpark at quake.net  Fri Nov 20 21:17:59 1998
From: donpark at quake.net (Don Park)
Date: Mon Jun  7 17:06:39 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <002401be14cb$52e3ccd0$2ee044c6@arcot-main>

>Instead of an internal subset B of an external schema A, would it be better
>to make B also an external schema "inheriting" A in some way?
>(For general processing, stylesheets, reuse etc, wouldn't it be best to
>externalize as much as possible?)


Interesting question.  I just found out that XSchema does allow inline
XSchema elements (5.1.2) but I am not sure if it supports schema
inheritance.

Actually, my questions were more or less regarding existing support.  DCD,
XML-Data, and RDF does not seem to support inline schema although they do
allow declaration of datatypes in data instances.

I think inline schema is particularly important in applications like digital
television and smart cable boxes where content variation is tremendous.  It
is possible to do this through multiplexing/tunneling but it would be nice
to have a single stream of XML data which can handle open variety of
contents (drama, shows, program schedule, advertisement, closed captions,
etc.)

Don Park



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From BPosert at filenet.com  Fri Nov 20 23:24:11 1998
From: BPosert at filenet.com (Posert, Bob)
Date: Mon Jun  7 17:06:39 2004
Subject: Entities with expat
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F45B162@hq-expo2.filenet.com>

I'm working with the unicode-wchar_t version of expat.  It looks like expat
doesn't do the entity translation, such as turning:
	<explain>5 is more than, or >, 3</explain>
into:
	<explain>5 is more than, or &gt;, 3</explain>
though the sample program xmlwf does.  Expat also doesn't interpret the
entities.  Is there some sample code around that does this efficiently?

Thanks,
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sat Nov 21 10:52:47 1998
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:06:39 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: "Don Park"'s message of "Fri, 20 Nov 1998 11:05:51 -0800"
References: <00aa01be14b8$ce365dc0$2ee044c6@arcot-main>
Message-ID: <f5bsofd5nd7.fsf@cogsci.ed.ac.uk>

"Don Park" <donpark@quake.net> writes:

> A simple question: does any of the new schema proposals have something
> equivalent to internal subset?  In other words, does DCD, XML Schema,
> XML-Data, RDF Schema, or XSchema allow schema to be placed in the same file
> as data?

The XML Schema working group is in the requirements drafting stage,
and this requirement has been entered on the list for consideration.

ht [NOT speaking officially for the WG]
-- 
  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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From murray at muzmo.com  Sat Nov 21 13:45:51 1998
From: murray at muzmo.com (Murray Maloney)
Date: Mon Jun  7 17:06:39 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: <00aa01be14b8$ce365dc0$2ee044c6@arcot-main>
Message-ID: <3.0.1.32.19981121084553.006d595c@pop.uunet.ca>

At 02:05 PM 11/20/98 -0500, Don Park wrote:
>A simple question: does any of the new schema proposals have something
>equivalent to internal subset?  In other words, does DCD, XML Schema,
>XML-Data, RDF Schema, or XSchema allow schema to be placed in the same file
>as data?
>
>Don Park
>Docuverse
>
To my knowledge, for the schema languages you mention, the answer is no.
And even though you did not ask, [SOX] does not either. But SOX does 
support an inheritance model.

[SOX] http://www.w3.org/Submission/1998/15/


Murray Maloney, Esq.          Phone: (905) 509-9120
Muzmo Communication Inc.      Fax:   (905) 509-8637
671 Cowan Circle              Email: murray@muzmo.com
Pickering, Ontario 		Email: murray@yuri.org
Canada, L1W 3K6    		

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Sat Nov 21 14:48:35 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:39 2004
Subject: XLink Open Source, continued
Message-ID: <199811211448.JAA15916@hesketh.net>

The XLinkFilter library has continued to grow.  Although it remains quite
definitely alpha, there are at least some useful (though perhaps crufty)
examples now available to try out and examine.  The applet example is a
significantly rebuilt version of the extended links applet for Building XML
Applications, if any of you have already visited that.

More information is available at
http://www.simonstl.com/projects/xlinkfilter/. All code is open source.
(Licensing still under development, but it will be usable in commercial
projects in some form.)


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tlainevool at yahoo.com  Sat Nov 21 17:52:36 1998
From: tlainevool at yahoo.com (Toivo Lainevool)
Date: Mon Jun  7 17:06:39 2004
Subject: SAX drivers bug ... or feature !
Message-ID: <19981121175517.5735.rocketmail@send105.yahoomail.com>

---Ronald Bourret <rbourret@ito.tu-darmstadt.de> wrote:
>
> Patrice Bonhomme wrote:
> 
> > I think there is a little problem with AttributeList implementation 
> within
> > some of the SAX drivers (i have tested the following code with my
SXP SAX 
> > driver, the XML4J SAX driver and the AELFRED SAX driver. We are all 
> giving the
> > same results (gosh...).
> >
> > This code should write the size of each AttributeList that has
been read 
> by
> > the parser when it reached the end of the Document. But it always
prints 
> the
> > size of the last AtributeList found.
> >
> > [code snipped]
> 
> It is a good bet that all the parsers are doing what I have done in
my 
> parsers: used a single instance of an AttributeList object, then
cleared it 
> and reused it for each call to startElement.  Thus, all the
references in 
> your Vector point to the same object.
> 
> This is specifically allowed by the SAX spec.  The documentation for 
> AttributeList states, "The instance provided will return valid
results only 
> during the scope of the startElement invocation (to save it for
future use, 
> the application must make a copy: the AttributeListImpl helper class 
> provides a convenient constructor for doing so)."

Instead of clearing and reusing the the AttributeList object, wouldn't
it be better to create a new attribute list object?  If the old
Attribute list isn't being referenced, it will be garbage collectible.
If the old Attribute list is being reference, it won't be changed out
from under the client.  This way of doing it seems to offer the best
of both worlds.

Toivo Lainevool


 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 21 18:10:25 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:39 2004
Subject: SAX drivers bug ... or feature !
In-Reply-To: <19981121175517.5735.rocketmail@send105.yahoomail.com>
References: <19981121175517.5735.rocketmail@send105.yahoomail.com>
Message-ID: <13910.65083.960328.511476@localhost.localdomain>

Toivo Lainevool writes:

 > Instead of clearing and reusing the the AttributeList object,
 > wouldn't it be better to create a new attribute list object?  If
 > the old Attribute list isn't being referenced, it will be garbage
 > collectible.  If the old Attribute list is being reference, it
 > won't be changed out from under the client.  This way of doing it
 > seems to offer the best of both worlds.

Depending on the virtual machine, this could be a killer.  Remember
that a medium-sized XML document (such as a book) might have 10,000
elements: that would mean an extra 10,000 attribute lists allocated
and then garbage collected in what should be only a few seconds of
parsing.

In fact, since AttributeList is an interface, drivers often implement
it themselves rather than allocating an object for it, as in

  import org.xml.sax.Parser;
  import org.xml.sax.AttributeList;

  public class MySAXDriver implements Parser, AttributeList
  {
    ...
  }

SAX was designed to be flexible so that people could write
highly-optimised implementations like this if they wanted.  It's also
designed to work with languages that don't support GC out-of-the-box,
like C++.

However, we also recognised that people might want to keep around
attribute lists sometimes, so we made it very easy by adding the
org.xml.sax.helpers.AttributeListImpl class with a copy constructor:

  AttributeList persistentAtts

  public void startElement (String name, AttributeList atts)
  {
    persistentAtts = new AttributeListImpl(atts);
  }

This approach does give you the best of both worlds -- it is trivially
easy to make a persistent copy when you need to, but you're not stuck
with the allocation/gc overhead when you don't need 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tlainevool at yahoo.com  Sat Nov 21 19:01:21 1998
From: tlainevool at yahoo.com (Toivo Lainevool)
Date: Mon Jun  7 17:06:39 2004
Subject: SAX drivers bug ... or feature !
Message-ID: <19981121190205.20510.rocketmail@send104.yahoomail.com>






---david@megginson.com wrote:
> 
> Depending on the virtual machine, this could be a killer.  Remember
> that a medium-sized XML document (such as a book) might have 10,000
> elements: that would mean an extra 10,000 attribute lists allocated
> and then garbage collected in what should be only a few seconds of
> parsing.
>

If your worried about the performance of the parser, just setting the
attributeList to null would be faster than doing the
AttributeListImpl::clear() which would cause a removeAllElement() on
each of the underlying member vectors.  If your cranking away with the
parser, chances are the low priority gc task wouldn't be fired while
your doing this, unless you hit your memory limit.

If your worried about memory space,  the clear() and resulting
resulting removeAllAttributes() would allow you to reuse the
AttributeListImpl and Vector objects, but the removeAllElements just
releases their hold on the underlying String within the vectors,
meaning that the Strings, which I assume would count for most of the
memory would be left hanging around for the gc to free anyway.

So which of these approaches would result in a more optimized parser
would highly depend on the size of the document, the amount of memory
you have available, and the gc algorithm your VM uses.

Toivo Lainevool

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 21 19:08:27 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:39 2004
Subject: SAX drivers bug ... or feature !
In-Reply-To: <19981121190205.20510.rocketmail@send104.yahoomail.com>
References: <19981121190205.20510.rocketmail@send104.yahoomail.com>
Message-ID: <13911.3634.738329.438745@localhost.localdomain>

Toivo Lainevool writes:

 > If your worried about the performance of the parser, just setting
 > the attributeList to null would be faster than doing the
 > AttributeListImpl::clear() which would cause a removeAllElement()
 > on each of the underlying member vectors.  If your cranking away
 > with the parser, chances are the low priority gc task wouldn't be
 > fired while your doing this, unless you hit your memory limit.

You're confusing AttributeListImpl with AttributeList -- AttributeList
is an interface, not a class.  While AttributeListImpl is available
for those who want it (such as a client program that needs to copy a
few attribute lists), most SAX drivers provide a more efficient
implementation, which is often an adapter of the parser's own, native
interface.


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


From tlainevool at yahoo.com  Sat Nov 21 20:53:29 1998
From: tlainevool at yahoo.com (Toivo Lainevool)
Date: Mon Jun  7 17:06:40 2004
Subject: SAX drivers bug ... or feature !
Message-ID: <19981121205409.29767.rocketmail@send104.yahoomail.com>






---david@megginson.com wrote:
>
> Toivo Lainevool writes:
> 
>  > If your worried about the performance of the parser, just setting
>  > the attributeList to null would be faster than doing the
>  > AttributeListImpl::clear() which would cause a removeAllElement()
>  > on each of the underlying member vectors.  If your cranking away
>  > with the parser, chances are the low priority gc task wouldn't be
>  > fired while your doing this, unless you hit your memory limit.
> 
> You're confusing AttributeListImpl with AttributeList -- AttributeList
> is an interface, not a class.  While AttributeListImpl is available
> for those who want it (such as a client program that needs to copy a
> few attribute lists), most SAX drivers provide a more efficient
> implementation, which is often an adapter of the parser's own, native
> interface.

I won't waste any more bandwidth on this list going into more
implementation details and performance ramifications, but i'd just
like to finish this though off. (I wouldn't mind discussing this issue
off of the list if anyone wants to continue it.)

There seems to be a tradeoff here between ease of use of the parser
(the client code needs to know to copy the AttributeList to hang onto
it) vs. flexibility of parser implementation (allowing the parser to
re-use the Attribute list).  This decision depends on the motivation
of the original design.  Since David was involved in this and I
wasn't, I won't second guess the decision.  I think as long as the
ramification of this decision is recorded properly in the
documentation, it shouldn't be a problem.


Thnaks,

Toivo Lainevool
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tyler at infinet.com  Sat Nov 21 21:45:32 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:40 2004
Subject: SAX drivers bug ... or feature !
References: <19981121175517.5735.rocketmail@send105.yahoomail.com>
Message-ID: <365734C0.F16CE2A@infinet.com>

Toivo Lainevool wrote:

> ---Ronald Bourret <rbourret@ito.tu-darmstadt.de> wrote:
> >
> > Patrice Bonhomme wrote:
> >
> > > I think there is a little problem with AttributeList implementation
> > within
> > > some of the SAX drivers (i have tested the following code with my
> SXP SAX
> > > driver, the XML4J SAX driver and the AELFRED SAX driver. We are all
> > giving the
> > > same results (gosh...).
> > >
> > > This code should write the size of each AttributeList that has
> been read
> > by
> > > the parser when it reached the end of the Document. But it always
> prints
> > the
> > > size of the last AtributeList found.
> > >
> > > [code snipped]
> >
> > It is a good bet that all the parsers are doing what I have done in
> my
> > parsers: used a single instance of an AttributeList object, then
> cleared it
> > and reused it for each call to startElement.  Thus, all the
> references in
> > your Vector point to the same object.
> >
> > This is specifically allowed by the SAX spec.  The documentation for
> > AttributeList states, "The instance provided will return valid
> results only
> > during the scope of the startElement invocation (to save it for
> future use,
> > the application must make a copy: the AttributeListImpl helper class
> > provides a convenient constructor for doing so)."
>
> Instead of clearing and reusing the the AttributeList object, wouldn't
> it be better to create a new attribute list object?  If the old
> Attribute list isn't being referenced, it will be garbage collectible.
> If the old Attribute list is being reference, it won't be changed out
> from under the client.  This way of doing it seems to offer the best
> of both worlds.

Well performance is an issue and calling new() for each attribute list creation
would incur significant overhead regardless of whether you are using Java or C++
or calling malloc in C.  You can consider the attribute list in SAX to be fail
fast, just like the java.util.Iterator implementations in the new Collections
framework.

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


From tyler at infinet.com  Sat Nov 21 21:54:46 1998
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun  7 17:06:40 2004
Subject: SAX drivers bug ... or feature !
References: <19981121190205.20510.rocketmail@send104.yahoomail.com>
Message-ID: <36573700.6AAFB1A6@infinet.com>

Toivo Lainevool wrote:

> ---david@megginson.com wrote:
> >
> > Depending on the virtual machine, this could be a killer.  Remember
> > that a medium-sized XML document (such as a book) might have 10,000
> > elements: that would mean an extra 10,000 attribute lists allocated
> > and then garbage collected in what should be only a few seconds of
> > parsing.
> >
>
> If your worried about the performance of the parser, just setting the
> attributeList to null would be faster than doing the
> AttributeListImpl::clear() which would cause a removeAllElement() on
> each of the underlying member vectors.  If your cranking away with the
> parser, chances are the low priority gc task wouldn't be fired while
> your doing this, unless you hit your memory limit.
>
> If your worried about memory space,  the clear() and resulting
> resulting removeAllAttributes() would allow you to reuse the
> AttributeListImpl and Vector objects, but the removeAllElements just
> releases their hold on the underlying String within the vectors,
> meaning that the Strings, which I assume would count for most of the
> memory would be left hanging around for the gc to free anyway.
>
> So which of these approaches would result in a more optimized parser
> would highly depend on the size of the document, the amount of memory
> you have available, and the gc algorithm your VM uses.

Simply put, the number one killer in XML parsing as well as application use of
XML data is creation of temporary handler objects.  In the native interface of
the parser we have, we have utility routines for our CharacterData interface (as
well as AttributeList interface) for parsing raw booleans, integers, base64
content mainly because the java.lang.Integer utility routines only accept Strings
)-:

For some applications which are performance sensitive, creating the temporary
String object needed to call Integer.parseInt(String s) can really bog things
down.

I feel and many others seem to feel that XML Parsers are in the same league as
I/O libraries in terms of their need to be optimized as best as possible,
especially for server environments.  That includes making the parser itself fast
in tokenizing the content as well as making the handling of the parsed content to
the application as fast as possible.  From the application developers perspective
what is important in a component like an XML Parser is that first the component
is fast, and second that the code you have to write to use the component is not
slow, something unfortunately many tools vendors often neglect.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sat Nov 21 22:20:29 1998
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun  7 17:06:40 2004
Subject: [Announce] rpm2html-1.0 and rpmfind-1.0
Message-ID: <19981121172006.A27839@w3.org>

  The version 1.0 of rpm2html and rpmfind tools has been released.
I send the announcement to these lists to provide an example of
an actual use of RDF based metadata. I have just seen too many mails
like "there is no XML/RDF applications" so this is at least one !

  To put it in a nutshell, rpm2html is a metadata extractor for RPM
software package (Redhat/linux packages but this have been ported to
other platforms), it generates both HTML pages and XML/RDF Metadata
for these packages.

  The RDF metadata are in turn mirrored and used to produce mirror
web sites. The metadata database also contains informations about
the RDF databases mirrors (half a dozen worldwide). So this is an
example of the use of XML/RDF for Web sites replication.

  But the most important use of these RDF databases is the rpmfind tool.
On a platform where the RPM packaging system is installed, rpmfind
allow to search, locate, upgrade and transfer software. The transfers
are done through HTTP (or FTP for the downloads), and the mirrors metadata
are used to select the closest available RDF and FTP mirrors. Rpmfind
also does the dependencies checking between packages to avoid the problems
related to incompatible or not up-to-date libraries.
  
  The software is based on the RPM library, an XML parser/generator,
a small RDF API, libWWW for the network accesses and some glue code.
Rpm2html also has some extra code for extracting the metadata, generating
indexes and producing HTML code.

  Some figures: 1000 downloads of rpmfind-1.0 in one week, 32000+ packages
                indexed (25+ GB), 800 MBytes of generated HTML, 250MBytes
		of RDF files, 75000 hits/months for the RDF files, 1MHits/m
		for the HTML output on rufus mirror.

Pointers:
  Home page: http://rufus.w3.org/linux/rpm2html/
             http://rufus.w3.org/linux/rpm2html/rpmfind.html
  CVS base : http://dev.w3.org/cgi-bin/cvsweb
  HTML     : http://rufus.w3.org/linux/RPM/
  RDF      : http://rufus.w3.org/linux/RDF/

Daniel

-- 
Daniel.Veillard@w3.org | W3C  MIT/LCS  NE43-344  | Today's Bookmarks :
Tel : +1 617 253 5884  | 545 Technology Square   | Linux, WWW, rpm2html,
Fax : +1 617 258 5999  | Cambridge, MA 02139 USA | badminton, Kaffe,
http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Sun Nov 22 00:06:54 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:40 2004
Subject: [Announce] rpm2html-1.0 and rpmfind-1.0
In-Reply-To: <19981121172006.A27839@w3.org>
References: <19981121172006.A27839@w3.org>
Message-ID: <13911.21380.353439.720634@localhost.localdomain>

[CC's removed]

Daniel Veillard writes:

 >   The version 1.0 of rpm2html and rpmfind tools has been released.
 > I send the announcement to these lists to provide an example of an
 > actual use of RDF based metadata. I have just seen too many mails
 > like "there is no XML/RDF applications" so this is at least one !

If endorsements have any value here, I'd like to mention that I've
been using an earlier version of rpmfind on my Linux system for a few
weeks now, and I find it robust and (already) indispensible.  It is
wonderful to be able to type something like

  rpmfind cvsweb

and have rpmfind offer to download the correct package for me,
together with any dependencies; not that I don't love AltaVista, but
the two of us already spend far too much time together.

Just in case you're interested, here are some samples from the RDF
index that gets downloaded to $(HOME)/.rpmfinddir/fullIndex.rdf.gz
(the namespace prefixes are declared higher up):

  <RDF:Description about="ftp://rufus.w3.org/linux/gnome.org/GNOME/redhat/latest/SRPMS/libxml-0.30-1.src.rpm">
    <RPM:Name>libxml</RPM:Name>
    <RPM:Summary>libXML library</RPM:Summary>
  </RDF:Description>

  <RDF:Description about="ftp://rufus.w3.org/linux/gnome.org/GNOME/redhat/latest/i386/libxml-devel-0.30-1.i386.rpm">
    <RPM:Name>libxml-devel</RPM:Name>
    <RPM:Summary>Libraries, includes, etc to develop libxml applications</RPM:Summary>
  </RDF:Description>


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


From kacper at odi.com  Sun Nov 22 00:11:22 1998
From: kacper at odi.com (Kacper Nowicki)
Date: Mon Jun  7 17:06:40 2004
Subject: Topic Maps on SQL
In-Reply-To: <199811191730.MAA13298@chmls05.mediaone.net>
Message-ID: <4.1.19981121144132.0332e5f0@mailhost.odi.com>


>>I am reasonably sure that one can implement topic map 
>>functionality in a set of relational tables and SQL queries, 
>>and then, as with RDF, export a compliant SGML/XML instance 
>>of that information.  Do you know of any reason why this 
>>would not work?

[...]

>With both database models, however, you still have the column problem,
>though.  I doubt the above would be sufficient for real world document
>repositories. 

There is this deep feeling in Object Database community, that XML and
dynamic content in general is task for us. XML structures are easily
repersented as objects with links/pointers to other objects and dynamic
collections of their nested objects, attributes, etc.

Kacper


---
Kacper Nowicki                                           kacper@odi.com
Senior Consulting Engineer                               (415) 286 6614
Object Design, Inc.                         http://www.objectdesign.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From srn at techno.com  Sun Nov 22 01:11:30 1998
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:06:40 2004
Subject: Topic Maps on SQL
In-Reply-To: <4.1.19981121144132.0332e5f0@mailhost.odi.com> (message from
	Kacper Nowicki on Sat, 21 Nov 1998 14:57:01 -0800)
References: <4.1.19981121144132.0332e5f0@mailhost.odi.com>
Message-ID: <199811220109.TAA02501@bruno.techno.com>

[Kacper Nowicki:]

> There is this deep feeling in Object Database community, that XML and
> dynamic content in general is task for us. XML structures are easily
> repersented as objects with links/pointers to other objects and dynamic
> collections of their nested objects, attributes, etc.

Yes.  Ever heard of property sets?  These provide vendor-neutral
information set models for "groves", the abstract object/node trees
resulting from parsing and processing data in many notations,
including XML, and including particular semantic models such as XLinks
and topic maps that are best regarded as inheritable information
architectures ("architectural forms") in XML.

Recommended reading: http://www.prescod.net/groves/shorttut

-Steve

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

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov 22 04:12:31 1998
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:06:40 2004
Subject: New expat versions
Message-ID: <36578DF4.49426E9E@jclark.com>

Version 1.0.1 of expat is now available. See

  http://www.jclark.com/xml/expat.html

The only changes from 1.0 are bug fixes.  This is a stable version
intended for production use.

There is also a test version available from

  ftp://ftp.jclark.com/pub/test/expat.zip

This includes new features including support for namespaces.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 22 04:43:11 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:40 2004
Subject: Topic Maps on SQL
References: <4.1.19981121144132.0332e5f0@mailhost.odi.com> <199811220109.TAA02501@bruno.techno.com>
Message-ID: <365795D6.1C24@hiwaay.net>

Steven R. Newcomb wrote:
> 
> [Kacper Nowicki:]
> 
> > There is this deep feeling in Object Database community, that XML and
> > dynamic content in general is task for us. XML structures are easily
> > repersented as objects with links/pointers to other objects and dynamic
> > collections of their nested objects, attributes, etc.
> 
> Yes.  Ever heard of property sets?  These provide vendor-neutral
> information set models for "groves", the abstract object/node trees
> resulting from parsing and processing data in many notations,
> including XML, and including particular semantic models such as XLinks
> and topic maps that are best regarded as inheritable information
> architectures ("architectural forms") in XML.
> 
> Recommended reading: http://www.prescod.net/groves/shorttut
> 
> -Steve

Quite.  But the initial question regarded a project where the 
implementation has been prototyped as a relational database.  
The tables thus far are not complex so any database implementation 
would do job currently.  However, one of the project members 
expressed an interest in using XML and potentially topic maps.  
Since the schedule is tight and members wish to present at a 
winter conference, I have suggested that they continue working 
with the relational model and inquire as to the feasibility of 
exporting topic maps at a later time.  If the topic map 
concepts are truly generalized, then exporting the properties 
and values of the relational tables, relationships, queries 
and scripting logic should enable such.  

Steve brings up the point that I do wish would be looked at 
seriously by other language communities:  the potential of 
using property set/grove concepts to create information 
standards that are independent of lexical/syntax representation 
and implementation.  As the VRML community is debating the 
concepts for the next generation of that language there 
is much discussion of a change towards context-free grammars 
and prototype based nodes (eg, the Balaguer paper).  XML 
has been cited as an example to emulate.  There exists 
an opportunity for different language communities to 
converge on common solutions.

The cycles for creating or ammending standards are long enough and
Internet 
Time cannot change that.  Furthermore, the period that the W3C can be 
counted on to provide a stable base of languages given the 
current proliferation of consortia and interests is passing. If there 
is an opportunity to put the web language standards on common ground 
and open up the technical frameworks for a more competitive 
development environment, it should not pass without serious
consideration.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 CanadaMail.com  Sun Nov 22 07:09:43 1998
From: gkholman at CanadaMail.com (G. Ken Holman)
Date: Mon Jun  7 17:06:40 2004
Subject: ISO/IEC Standardization Activities: Procedural Background
In-Reply-To: <3.0.5.32.19981114101714.008a33a0@amati.techno.com>
Message-ID: <Version.32.19981121145346.010ad770@CraneSoftwrights.com>

At 98/11/14 10:17 -0600, W. Eliot Kimber wrote:
>[Warning: boring but important standards stuff. Please read to the end if
>you can.]
>...
>If you are in the U.S., or you don't know who your SC34 delegates are (and
>I don't know why you would--we're not exactly international celebrities),
>you can forward your comments to me in my capacity as a member of the U.S.
>delegation to SC34 and I will either incorporate your comments with ours or
>pass them on to the appropriate national body, if there is one (not all ISO
>members send delegations to SC34).

For Canadian members of XML-DEV, I am the chair of the Canadian National
Body committee: CAC/ISO/IEC JTC 1/SC 34

The Canadian perspective of international standards is managed and
shepherded by the Standards Council of Canada.

There is a Canadian maillist for the work of the committee (quite quiet
lately), so if you wish to participate formally as a member of the Canadian
committee, please do not hesitate to contact me.

Thanks!

.......... Ken


--
G. Ken Holman               mailto:gkholman@CanadaMail.com
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/m/
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
Training:   http://www.CraneSoftwrights.com/m/schedule.htm
Resources: http://www.CraneSoftwrights.com/m/resources.htm
Shareware: http://www.CraneSoftwrights.com/m/shareware.htm


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 CanadaMail.com  Sun Nov 22 07:12:07 1998
From: gkholman at CanadaMail.com (G. Ken Holman)
Date: Mon Jun  7 17:06:40 2004
Subject: Definitive test suite? (was Re: Oracle XML)
In-Reply-To: <3.0.5.32.19981115050420.00f3b990@scripting.com>
References: <199811150502.AAA05690@hesketh.com>
 <364E030D.FD0F3655@finetuning.com>
 <Pine.GSO.3.95.981110165049.7882A-100000@betty.cnidr.org>
 <364AB030.EFAC2ADE@sophia.inria.fr>
 <364B6296.3598F440@infinet.com>
Message-ID: <Version.32.19981121153054.010abc00@CraneSoftwrights.com>

At 98/11/15 05:04 -0800, Dave Winer wrote on the XML-DEV mailing list:
>There still is no definitive test suite of XML files they have to parse. If
>we're serious about having compatibility and offering users real choices,
>we can probably still fix this, but soon, the cat will be out of the bag,
>as they say, and it'll be too late. 
>
>No individual commercial vendor has the credibility or motivation to
>establish this test suite. 

The Organization for the Advancement of Structured Information Standards
(OASIS - http://www.oasis-open.org) has established the XML Conformance
subcommittee of its technical committee to address this issue.

An industry consortium of users, vendors and invited experts, OASIS members
volunteer to collaborate in the development of resources to contribute to
the community at large.  When complete, said resources are made available
to the entire community without constraints ... it is a benefit of
membership in the consortium to be involved in the development of technical
reports.

I am currently chairing this volunteer group which has, due to constraints
on the available time of contributing members, not been very visible.

The first deliverable from the subcommittee will be a report on XML
Conformance, complete with a suite of test files.  These test files do not
include the tests from James Clark, so the community will have hundreds of
additional test files than what is available today.

During the XML Conference in Chicago last week, impromptu meetings with
members resulted in new and renewed commitments to the effort which should
produce results more quickly than in the past.

Of note, the subcommittee has the valuable contribution from NIST of
expertise directly related to conformance testing that has been committed
to the effort, and I have begun sharing the subcommittee chair duties with
Mary Brady who was instrumental in the development of the VRML Conformance
work.

I will report to this group on the availability of results of the work of
the committee, and how the committee decides to solicit input from the
community on any draft work that may be released.

Any contributions of test files made without any strings attached will be
gratefully considered by the committee for inclusion in the report, and any
such materials that are included in the final report will be attributed.

We on the committee are interested to receive comments on your own
perspectives regarding XML Conformance ... if you are employed by an OASIS
member company, please find your representative and make your feelings
known; if you deal with an OASIS member company, you can forward your
comments through them; you are welcome to send me your comments, and we are
temporarily using my FTP site ftp://ftp.CraneSoftwrights.com for any
contributions.

Thank you!

.......... Ken

--
G. Ken Holman               mailto:gkholman@CanadaMail.com
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/x/
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
Training:   http://www.CraneSoftwrights.com/x/schedule.htm
Resources: http://www.CraneSoftwrights.com/x/resources.htm
Shareware: http://www.CraneSoftwrights.com/x/shareware.htm


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sun Nov 22 09:17:59 1998
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:06:40 2004
Subject: New expat versions
References: <36578DF4.49426E9E@jclark.com>
Message-ID: <3657C268.90CD437B@jclark.com>

I forgot to say that I am now allowing use of expat under the GNU
General Public License as an alternative to the Mozilla Public License.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 ozemail.com.au  Sun Nov 22 12:20:43 1998
From: abcoates at ozemail.com.au (Anthony B. Coates)
Date: Mon Jun  7 17:06:40 2004
Subject: Applying DTDs to sub-documents
Message-ID: <199811221220.XAA12052@fep7.mail.ozemail.net>

I'm sure this must have been dealt with some time ago, so my apologies in
advance, but has anyone been applying DTDs to sub-documents, e.g. you have an
XML document (without a DTD) like

<?xml version="1.0"?>
<document>
  <head>
    <title>The Title</title>
  </head>
  <body>
    <equation dtd="equation.dtd">
      <variable>a</variable>
      <equals/>
      <variable>b</variable>
    </equation>
  </body>
</document>

and you only want to apply the DTD to a particular section, in this case the
<equation> tag and its children.  What I would really like is to have my XML
parser produce a tag stream, and then have the appropriate part of the tag
stream validated against the DTD.  However, looking at how current parsers work,
it seems more like what I would have to do is
(i) parse the document
(ii) intercept the <equation> tag and its siblings
(iii) generate an intermediate XML document from (ii)
(iv) parse the intermediate document using the DTD
which involves an extra "tags -> XML test -> tags" round-trip that I would have
preferred to avoid.

Can anyone tell me if there is a better way than what I have described above? 
I'm sure I won't be the only one wanting to do this, so some of you must already
have had much better ideas than my own.  Anyway, if anyone has any hints, I
would be very grateful for them.

	Cheers,
			Tony.

** Anthony B. Coates
** Software Engineer (Java).  This is a 100% Pure Java e-mail.
** <mailto:abcoates@ozemail.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rob at robco-inc.com  Sun Nov 22 14:19:52 1998
From: rob at robco-inc.com (Rob Williams)
Date: Mon Jun  7 17:06:40 2004
Subject: Transports for XML Streaming?
Message-ID: <773251A595CFD111B8F800A0C998C55102CF51@ris3.robco-inc.com>

I just finished doing an e-commerce web site using Java. I want to make it
so that participants in our buy/sell network can stream us updates (i.e.
list new products or tell us that other things they had listed have been
sold). I want to do this w/XML. My question is, should I hang a socket off
my program that is waiting for XML to be streamed to it or should I make it
so that I have a server-based mailbox that XML files are sent to? What have
other people done for this kind of application?

Thanks,

Rob Williams
RobCo Incorporated


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From gkholman at CanadaMail.com  Sun Nov 22 16:54:42 1998
From: gkholman at CanadaMail.com (G. Ken Holman)
Date: Mon Jun  7 17:06:40 2004
Subject: Definitive test suite? (was Re: Oracle XML) [RETRY]
Message-ID: <Version.32.19981122085209.00ef42c0@CraneSoftwrights.com>

At 98/11/15 05:04 -0800, Dave Winer wrote on the XML-DEV mailing list:
>There still is no definitive test suite of XML files they have to parse. If
>we're serious about having compatibility and offering users real choices,
>we can probably still fix this, but soon, the cat will be out of the bag,
>as they say, and it'll be too late. 
>
>No individual commercial vendor has the credibility or motivation to
>establish this test suite. 

The Organization for the Advancement of Structured Information Standards
(OASIS - http://www.oasis-open.org) has established the XML Conformance
subcommittee of its technical committee to address this issue.

An industry consortium of users, vendors and invited experts, OASIS members
volunteer to collaborate in the development of resources to contribute to
the community at large.  When complete, said resources are made available
to the entire community without constraints ... it is a benefit of
membership in the consortium to be involved in the development of technical
reports.

I am currently chairing this volunteer group which has, due to constraints
on the available time of contributing members, not been very visible.

The first deliverable from the subcommittee will be a report on XML
Conformance, complete with a suite of test files.  These test files do not
include the tests from James Clark, so the community will have hundreds of
additional test files than what is available today.

During the XML Conference in Chicago last week, impromptu meetings with
members resulted in new and renewed commitments to the effort which should
produce results more quickly than in the past.

Of note, the subcommittee has the valuable contribution from NIST of
expertise directly related to conformance testing that has been committed
to the effort, and I have begun sharing the subcommittee chair duties with
Mary Brady who was instrumental in the development of the VRML Conformance
work.

I will report to this group on the availability of results of the work of
the committee, and how the committee decides to solicit input from the
community on any draft work that may be released.

Any contributions of test files made without any strings attached will be
gratefully considered by the committee for inclusion in the report, and any
such materials that are included in the final report will be attributed.

We on the committee are interested to receive comments on your own
perspectives regarding XML Conformance ... if you are employed by an OASIS
member company, please find your representative and make your feelings
known; if you deal with an OASIS member company, you can forward your
comments through them; you are welcome to send me your comments, and we are
temporarily using my FTP site ftp://ftp.CraneSoftwrights.com for any
contributions.

Thank you!

.......... Ken 

--
G. Ken Holman               mailto:gkholman@CanadaMail.com
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/x/
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
Training:   http://www.CraneSoftwrights.com/x/schedule.htm
Resources: http://www.CraneSoftwrights.com/x/resources.htm
Shareware: http://www.CraneSoftwrights.com/x/shareware.htm


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From arabbit at earthlink.net  Sun Nov 22 17:34:26 1998
From: arabbit at earthlink.net (Paul Butkiewicz)
Date: Mon Jun  7 17:06:41 2004
Subject: Transports for XML Streaming?
In-Reply-To: <773251A595CFD111B8F800A0C998C55102CF51@ris3.robco-inc.com>
Message-ID: <000101be163e$7acea8e0$a639bfa8@arabbit>

Hi Rob:

I've actually developed a solution for precisely what you're asking about.
It's pretty cool --- I think you'll like it.  If you'd like a copy or more
information, please drop me a line.

Paul Butkiewicz
arabbit@earthlink.net


-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
Rob Williams
Sent: Sunday, November 22, 1998 9:20 AM
To: 'xml-dev@ic.ac.uk'
Subject: Transports for XML Streaming?


I just finished doing an e-commerce web site using Java. I want to make it
so that participants in our buy/sell network can stream us updates (i.e.
list new products or tell us that other things they had listed have been
sold). I want to do this w/XML. My question is, should I hang a socket off
my program that is waiting for XML to be streamed to it or should I make it
so that I have a server-based mailbox that XML files are sent to? What have
other people done for this kind of application?

Thanks,

Rob Williams
RobCo Incorporated


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Mon Nov 23 00:06:57 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:41 2004
Subject: Invitation to participate in Coins - now open source
Message-ID: <199811230006.TAA07505@hesketh.net>

Many of you on this list have heard of Coins, a free tool for binding XML
documents to Java objects. Some of you have worked with it.  Now, you have
the opportunity to contribute to Coins and explore its source code. Coins
is now Open Source Software. We are just starting to work on Version 4 and
would appreciate your participation.

Version 3, the previous version, is now available with a BSD-style license
at http://www.jxml.com/.  Development of Version 4 is underway, and will be
carried out as an open source project.

The objectives of version 4 are:
    - provide better support for working with multiple documents;
    - develop a better data model;
    - support a wider range of mappings between documents and 
      the application objects;
    - make better use of reflection without a significant loss in speed; and
    - provide an alternative to code generation.

Paul Rabin is working on an initial draft of the version 4 DTDs as
well as a specification. It should be available sometime early this
week for review.

For more information, please visit http://www.jxml.com.


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Mon Nov 23 09:06:38 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:41 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <01BE16C8.3736EF90@grappa.ito.tu-darmstadt.de>

Don Park wrote:

> Interesting question.  I just found out that XSchema does allow inline
> XSchema elements (5.1.2) but I am not sure if it supports schema
> inheritance.
>
> Actually, my questions were more or less regarding existing support. 
 DCD,
> XML-Data, and RDF does not seem to support inline schema although they do
> allow declaration of datatypes in data instances.
>
> I think inline schema is particularly important in applications like 
digital
> television and smart cable boxes where content variation is tremendous. 
 It
> is possible to do this through multiplexing/tunneling but it would be 
nice
> to have a single stream of XML data which can handle open variety of
> contents (drama, shows, program schedule, advertisement, closed captions,
> etc.)

Neither DCD nor SOX define how a schema is associated with an instance 
file, so it's hard to say whether they have this capability.

XSchema uses a PI to associate a schema with an instance file and allows 
multiple PIs to be used.  The effect is cumulative, as if the schemas from 
all the referenced files were in a single file.  Thus, an instance could 
include a custom schema in addition to the standard schema.

However:

1) This isn't really the same as the relation between the internal and 
external subsets.  In particular, it is not possible to override/add 
attributes (these are inside element declarations and the duplicate element 
declaration needed to contain the new attribute would cause an error), nor 
is it possible to override/add parsed entities because XSchema does not 
support parsed entities.

2) XSchema PIs that occur after the root element are ignored, so this 
doesn't help in your case.

Note also the inline XSchema elements (which we included based on your 
suggestion of last August) are considered experimental and subject to 
change.

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov 23 09:43:49 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:41 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <001b01be16c5$1abdfe60$7008e391@bra01wmhkay.bra01.icl.co.uk>


Don Park wrote:
>I think inline schema is particularly important in applications like
digital
>television and smart cable boxes where content variation is tremendous.

I think inline schema is absolutely pernicious in such applications (which
is the area I am currently working in). The idea that a content author can
subvert the intentions of the content designer by modifying the schema on a
per-instance basis is too horrible to contemplate. There is an application
(perhaps in the set top box) that thinks it understands the structure of
things like the electronic programme guide, and that therefore relies on
today's guide conforming to the same schema as yesterday's.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov 23 09:59:15 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:41 2004
Subject: Transports for XML Streaming?
Message-ID: <008501be16c7$44b491a0$7008e391@bra01wmhkay.bra01.icl.co.uk>

Rob Williams wrote:
>I just finished doing an e-commerce web site using Java.

It sounds to me as if you've just started...

> I want to make it
>so that participants in our buy/sell network can stream us updates (i.e.
>list new products or tell us that other things they had listed have been
>sold). I want to do this w/XML. My question is, should I hang a socket off
>my program that is waiting for XML to be streamed to it or should I make it
>so that I have a server-based mailbox that XML files are sent to? What have
>other people done for this kind of application?


Suggest you look at message queuing technology ( www.messageQ.com ). We are
using Microsoft's MSMQ for this purpose, others use IBM's MQSeries.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From BPosert at filenet.com  Mon Nov 23 18:27:51 1998
From: BPosert at filenet.com (Posert, Bob)
Date: Mon Jun  7 17:06:41 2004
Subject: Expat user group or mailing list?
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F45B167@hq-expo2.filenet.com>

Is there a user group or mailing list for expat users?  I'm running into
some 
issues that other people may have solved:
- I can't get a simple program using XML_UNICODE_WCHAR_T to work.
- I'm curious as to known bugs, and the bugs fixed in the latest release.
- What's the best way to distribute xmlparse.dll/xmltok.dll?  I'm thinking
of 
  building dlls named <my-company-prefix>-xmlparse.dll, and
<my-company-prefix>xmltok.dll,
  with version information embedded, so that our install can track versions.
We may also have 
  to build <m-c-p>xmlparseU.dll for UNICODE releases.  But, then, we'll have
to download over 
  the web even if Mozilla is installed.

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


From docjah at wizvax.net  Mon Nov 23 18:33:03 1998
From: docjah at wizvax.net (Dave Geoghegan)
Date: Mon Jun  7 17:06:41 2004
Subject: Pretty Printing XML
Message-ID: <3659AC9F.9977E145@wizvax.net>

Hi,

  I'm making XML documents with a DOM implementation. When I save these
to a file (rootElement.toString()) it has no line breaks etc. I could
slap in a line break element in each element but I'd rather not.

 Is there a way to
   a) pretty print XML - (DOMWriter??)
   b) ignore whitespace on XMLdocument load?

 Right now I'm using jclark's stuff, but it's all SAX based so the
choice of parser is not that critical.

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


From tomo at everyware.com  Mon Nov 23 19:27:50 1998
From: tomo at everyware.com (Tom Otvos)
Date: Mon Jun  7 17:06:41 2004
Subject: Expat user group or mailing list?
In-Reply-To: <C3AF5E329E21D2119C4C00805F6FF58F45B167@hq-expo2.filenet.com>
Message-ID: <000701be1717$499bb360$160410ac@nebula.everyware.com>

> Is there a user group or mailing list for expat users?  I'm running into
some
> issues that other people may have solved

I think that issues should be dealt with through xml-dev...I can't imagine a
more relevant forum.  I would be interested in finding out if there are
other users out there, however.  I know that I am coming across several
issues that I would not mind airing, such as:

- CDATA sections not sending the correct callback events
- getting the parser to understand high-order ascii characters

I, too, would be interested in a change history between revs.  Regarding
your distribution questions, we have not got there yet and have not
formulated a plan, so I am afraid I cannot offer any wisdom there.

Tom Otvos
Director of Research, Pervasive Software Inc.
"Try not! Do, or do not. There is no 'try'." - Yoda


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From donpark at quake.net  Mon Nov 23 21:56:45 1998
From: donpark at quake.net (Don Park)
Date: Mon Jun  7 17:06:41 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <013901be172c$394b0410$2ee044c6@arcot-main>

>I think inline schema is absolutely pernicious in such applications (which
>is the area I am currently working in). The idea that a content author can
>subvert the intentions of the content designer by modifying the schema on a
>per-instance basis is too horrible to contemplate. There is an application
>(perhaps in the set top box) that thinks it understands the structure of
>things like the electronic programme guide, and that therefore relies on
>today's guide conforming to the same schema as yesterday's.


IMHO, set top boxes designed with preconceived program structures will fail
to attract the interests of production houses and the audience.  I would
prefer to give creative artists a clean canvas to work with than forcing
them to 'color-by-number'.  Also, TV producers, the ultimate control freaks,
will not accept the harness given them by the DTD designers.

Don



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From srn at techno.com  Mon Nov 23 22:30:42 1998
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:06:41 2004
Subject: Topic Maps on SQL
In-Reply-To: <365795D6.1C24@hiwaay.net> (message from len bullard on Sat, 21
	Nov 1998 22:40:54 -0600)
References: <4.1.19981121144132.0332e5f0@mailhost.odi.com> <199811220109.TAA02501@bruno.techno.com> <365795D6.1C24@hiwaay.net>
Message-ID: <199811231905.NAA01057@bruno.techno.com>

[Len Bullard:]

> If the topic map concepts are truly generalized, then exporting the
> properties and values of the relational tables, relationships,
> queries and scripting logic should enable such.

Which is why I brought up the subject of groves and property sets.
Documents conforming to the topic map architecture, like documents
conforming to other inheritable information architectures, have
semantic properties that emerge when they are processed (made ready
for some useful application-defined purpose).  Property sets are a
good way to give names to those properties, so that the mapping
between any application's internal representation (including internal
representations that take the form of relational tables) and the
underlying abstract data model (the property set) of the inheritable
interchange architecture can be rigorous, testable, and easy to
implement without guesswork, and so that the properties represented by
the application-internal form can be addressed by other documents and
their applications.

> Steve brings up the point that I do wish would be looked at
> seriously by other language communities: the potential of using
> property set/grove concepts to create information standards that are
> independent of lexical/syntax representation and implementation.

Thanks, Len.  (I wish I had said that!)

-Steve

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

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 23 22:56:35 1998
From: roddey at us.ibm.com (roddey@us.ibm.com)
Date: Mon Jun  7 17:06:41 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <872566C5.007DDE92.00@us.ibm.com>




Hmmm... This is a totally "unencumbered by the thought process" suggestion,
but perhaps something like this could deal with a lot of issues that are
arising in this and related areas.

<XSC:Packet>
    <XSC:Schema>
        schema goes here....
   </XSC:Schema>

   <XSC:Data>
        XML data goes here
   </XSC:Data>
</XSC:Packet>

It would be a way of packing a schema and its data in a single file. Since
its a known format, the application can understand what is happening and
tear it apart and feed it back into the parser. Or, if its an official
concept, the parser itself can understand what is happening and make it all
automagical to a certain degree. Seems like it could be applicable in a
number of ways, though as I said before I pondered it all of 15 seconds
before saying this so it could be totally useless :-)

An extension of this packet would look something like this:

<XSC:Packet>
    <XSC:InternalEntities>
        define internal entities here
    </XSC:InternalEntities>

    <XSC:Schema>
        schema goes here....
   </XSC:Schema>

   <XSC:Data>
        XML data goes here
   </XSC:Data>
</XSC:Packet>

where an internal entities definition section could be provided, and which
must be first, so that entities could be preloaded into the entity pool in
order to affect the upcoming parsing of the schema file? If this were a
known format, it wouldn't be too hard for the parser to feed its own entity
pool and leave it populated for the next step. It would look just like they
were defined via a DTD and all of the same code would be used to handle the
entity expansion and reference replacement, right?

Just a thought anyway...

>>Instead of an internal subset B of an external schema A, would it be
better
>>to make B also an external schema "inheriting" A in some way?
>>(For general processing, stylesheets, reuse etc, wouldn't it be best to
>>externalize as much as possible?)
>
>Interesting question.  I just found out that XSchema does allow inline
>XSchema elements (5.1.2) but I am not sure if it supports schema
>inheritance.
>
>Actually, my questions were more or less regarding existing support.  DCD,
>XML-Data, and RDF does not seem to support inline schema although they do
>allow declaration of datatypes in data instances.
>
>I think inline schema is particularly important in applications like
digital
>television and smart cable boxes where content variation is tremendous.
It
>is possible to do this through multiplexing/tunneling but it would be nice
>to have a single stream of XML data which can handle open variety of
>contents (drama, shows, program schedule, advertisement, closed captions,
>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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 24 12:35:18 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:41 2004
Subject: "Chinese XML Now!" Project
Message-ID: <009b01be17a7$36f166c0$2cf96d8c@NT.JELLIFFE.COM.AU>

We are starting a project, probably called "Chinese XML Now!".

The aims are:

1) Help Chinese users to find out which XML tools support Chinese:
    * Chinese XML sample documents and test bed
    * Web page with results

2) Help Western XML (freeware) parser developers support Chinese XML
encodings:
    * port code to Chinese (i.e. the read/write routines)
    * make this code available to the developers to include in their
parsers, if they wish.

Initially we will target the Big5 encoding only. (Other groups may
contribute other Chinese encodings.)

We are interested in any other similar Chinese (or CJK) work in this area.
Please contact me if you can contribute time or code. (Email to me in
English if possible--do not worry if it is not perfect!)

 The purpose of the project is to fast-track the availability of XML tools
which can input or output Chinese character encodings correctly, so that XML
will be just as convenient in the Chinese context as it is for Western
documents.

I will post more details to this XML-DEV list as they firm up.


Rick Jelliffe
Computing Center,
Academia Sinica,
Taipei
ricko@gate.sinica.edu.tw


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jjc at jclark.com  Tue Nov 24 12:36:44 1998
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:06:41 2004
Subject: Expat user group or mailing list?
References: <C3AF5E329E21D2119C4C00805F6FF58F45B167@hq-expo2.filenet.com>
Message-ID: <365A7FBF.6BF65A9A@jclark.com>

Posert, Bob wrote:
> 
> Is there a user group or mailing list for expat users?

Not that I know of.

>  I'm running into
> some
> issues that other people may have solved:
> - I can't get a simple program using XML_UNICODE_WCHAR_T to work.

Unfortunately for things to work properly you need to define XML_UNICODE
as well as XML_UNICODE_WCHAR_T.  If you still have problems send me a
proper bug report.

> - What's the best way to distribute xmlparse.dll/xmltok.dll?  I'm thinking
> of
>   building dlls named <my-company-prefix>-xmlparse.dll, and
> <my-company-prefix>xmltok.dll,
>   with version information embedded, so that our install can track versions.
> We may also have
>   to build <m-c-p>xmlparseU.dll for UNICODE releases.

Unless you need access to the xmltok layer, you might find it more
convenient to have a single DLL that combines xmltok and xmlparse.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 24 12:38:33 1998
From: jjc at jclark.com (James Clark)
Date: Mon Jun  7 17:06:41 2004
Subject: Expat user group or mailing list?
References: <000701be1717$499bb360$160410ac@nebula.everyware.com>
Message-ID: <365A80FB.DCCC82DC@jclark.com>

Tom Otvos wrote:

> I know that I am coming across several
> issues that I would not mind airing, such as:
> 
> - CDATA sections not sending the correct callback events

Data inside CDATA sections is passed to the app in the same way as data
outside CDATA sections.  Expat (like SAX) doesn't tell you whether where
CDATA sections occur.  It may provide this information in a future
release.

> - getting the parser to understand high-order ascii characters

If your document isn't in UTF-8, then you need to tell expat either by
using an encoding argument to XML_CreateParser or by supplying an
appropriate encoding declaration, such as

<?xml version="1.0" encoding="iso-8859-1"?>

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 24 13:14:35 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:41 2004
Subject: Expat user group or mailing list?
Message-ID: <00a001be17ac$a2f4ab70$2cf96d8c@NT.JELLIFFE.COM.AU>

From: James Clark <jjc@jclark.com>

>If your document isn't in UTF-8, then you need to tell expat either by
>using an encoding argument to XML_CreateParser or by supplying an
>appropriate encoding declaration, such as
>
><?xml version="1.0" encoding="iso-8859-1"?>

Am I right in thinking that for a parser to conform the the RFC on MIME
types for XML, it must allow over-riding of the encoding declaration (i.e.
by a invocation argument of some kind)? (Ignoring the case where only UTF-8
and UTF-16 are supported by a parser.)

If a parser does not allow over-riding, what class of errors do we call
this? Is it a WF error, or does it just mean that that parser cannot be used
in a WWW client that must conform to the RFC (unless some pre-processor is
tacked on)?

Also, as a question of terminology, is there any common name for the
intersection of two character sets?  In particular, if we pivot a large
character set through a smaller one (changing non-intersection characters
with NCRs) and then back to the larger set (while keeping all the NCRs
belonging to the smaller set) in order to have XML files which can withstand
dumb transcoding, is there any terminology I can use?  Anyone got any idea?

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


From tomo at pervasive.com  Tue Nov 24 16:36:55 1998
From: tomo at pervasive.com (Tom Otvos)
Date: Mon Jun  7 17:06:41 2004
Subject: SAX in C++?
Message-ID: <002201be17c8$6b61c460$160410ac@nebula.everyware.com>

Are there any efforts underway to do a C++ version of SAX?  I know that
because of the dynamic class loading of Java, the C++ version would not be
as "functional" (short of requiring CORBA), but the motivation for having a
standard API to XML parsers is the same.

It should be a relatively simple exercise to put a SAX-like wrapper around
expat (has anyone done that???).  Are there, in fact, any other C or C++
parsers out there that need to be SAX-ified?  Or am I a standing on a lonely
little island in a large, Java-based XML sea?

Tom Otvos
Director of Research, Pervasive Software Inc.
"Try not! Do, or do not. There is no 'try'." - Yoda


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rja at arpsolutions.demon.co.uk  Tue Nov 24 17:12:06 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:41 2004
Subject: SAX in C++?
Message-ID: <002b01be17cd$01ab9870$c5010180@p197>

Hi,

I'm working on some C++ SAX definitions, and of course a C++ SAX
implementation.

The definitions can be found at :

http://www.arpsolutions.demon.co.uk/sax/sax.h

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 24 17:13:15 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:41 2004
Subject: SAX in C++?
Message-ID: <003001be17cd$0dfde470$c5010180@p197>

Hi,

I'm working on some C++ SAX definitions, and of course a C++ SAX
implementation.

The definitions can be found at :

http://www.arpsolutions.demon.co.uk/sax/sax.h

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 24 17:17:24 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:42 2004
Subject: SAX in C++?
Message-ID: <000201be17cd$de220aa0$c5010180@p197>

Hi,

I'm working on some C++ SAX definitions, and of course a C++ SAX
implementation.

The definitions can be found at :

http://www.arpsolutions.demon.co.uk/sax/sax.h

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 24 17:22:16 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:42 2004
Subject: SAX in C++?
Message-ID: <001e01be17ce$7dc580f0$c5010180@p197>

Hi,

I'm working on some C++ SAX definitions, and of course a C++ SAX
implementation.

The definitions can be found at :

http://www.arpsolutions.demon.co.uk/sax/sax.h

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 24 17:24:59 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:42 2004
Subject: SAX in C++?
Message-ID: <000b01be17ce$5a44e940$c5010180@p197>

Hi,

I'm working on some C++ SAX definitions, and of course a C++ SAX
implementation.

The definitions can be found at :

http://www.arpsolutions.demon.co.uk/sax/sax.h

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Tue Nov 24 17:25:36 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:42 2004
Subject: SAX in C++?
Message-ID: <004901be17cd$4ec65d70$c5010180@p197>

Hi,

I'm working on some C++ SAX definitions, and of course a C++ SAX
implementation.

The definitions can be found at :

http://www.arpsolutions.demon.co.uk/sax/sax.h

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Tue Nov 24 17:29:19 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:42 2004
Subject: Topic Maps on SQL
In-Reply-To: <365795D6.1C24@hiwaay.net>
References: <4.1.19981121144132.0332e5f0@mailhost.odi.com>
 <199811220109.TAA02501@bruno.techno.com>
Message-ID: <3.0.5.32.19981124111351.007c4100@amati.techno.com>

At 10:40 PM 11/21/98 -0600, len bullard wrote:

>Steve brings up the point that I do wish would be looked at 
>seriously by other language communities:  the potential of 
>using property set/grove concepts to create information 
>standards that are independent of lexical/syntax representation 
>and implementation.  

While I agree with the general sentiment and certainly agree that groves
are a useful and powerful abstraction for talking about and working with
data, I'm not sure if it's appropriate to push property sets as the
definitional mechanism.

This is because property sets are, by design, a relatively simple mechanism
for data model definition. They do what we needed for HyTime and DSSSL and
no more. This is their strength (relative simplicity) but also their
weakness, for there are many things they can't do.

This is why we are pursuing the harmonization of STEP's EXPRESS data
modeling language with SGML's grove idea.  We are close to having a
fully-cooked definition of the semantic mapping between the fundamental
constructs defined by the STEP standard (entities with attributes in a
traditional data modeling sense) and those defined by the grove approach
(nodes with properties). We have demonstrated to our satisfaction that
there is such a mapping and that it is useful.  We have created draft data
models reflecting the SGML property set, the HyTime property set (linking
and addressing information), and a property set template for generating
property sets from EXPRESS schemas.  We expect to have these solid enough
for public consumption early next year.

Given such a mapping, it becomes possible to use the full descriptive power
of EXPRESS (or it's non-standard equivalents like UML) to define abstract
data models and then *automatically* generate the property set needed to
define the grove view of that data abstraction.  We're focused on EXPRESS
because it is a standard, but there are existing mappings from EXPRESS to
commercial products and proprietary languages like UML.

This gives you the best of both worlds: a complete and powerful modeling
language, divorced from any syntax, coupled with a standardized data
abstraction optimized for the "document processing" domain.  In short, you
can eat your data model and have your grove.

The "STEP and SGML Harmonization" work (really STEP<->grove) is being
conducted as a preliminary work item under ISO TC184/SC4, the committee
responsible for the STEP family of standards (ISO 10303).  This work has
formal liaisons with both the W3C (in particular, the schema working group)
and with ISO/IEC JTC1/SC34, the SGML family of standards).  There are two
mailing lists, one for information and one for ongoing work, that anyone
with an interest can subscribe to.  The results of our formal committee
work is posted on the STEP web site, <http://www.nist.gov/sc4>.

We are in the process of writing up our findings for wider publication.
Expect to see documents available in February, soon after our next official
meeting (Last week in January in San Francisco).  If anyone is interested
in participating in this work or tracking it, feel free to contact me for
more information.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Tue Nov 24 17:29:47 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:42 2004
Subject: Topic Maps on SQL
In-Reply-To: <199811231905.NAA01057@bruno.techno.com>
References: <365795D6.1C24@hiwaay.net>
 <4.1.19981121144132.0332e5f0@mailhost.odi.com>
 <199811220109.TAA02501@bruno.techno.com>
 <365795D6.1C24@hiwaay.net>
Message-ID: <3.0.5.32.19981124111641.00a481d0@amati.techno.com>

At 01:05 PM 11/23/98 -0600, Steven R. Newcomb wrote:
>[Len Bullard:]
>
>> If the topic map concepts are truly generalized, then exporting the
>> properties and values of the relational tables, relationships,
>> queries and scripting logic should enable such.
>
>Which is why I brought up the subject of groves and property sets.
>Documents conforming to the topic map architecture, like documents
>conforming to other inheritable information architectures, have
>semantic properties that emerge when they are processed (made ready
>for some useful application-defined purpose).  

I have defined an EXPRESS data model representation of the Topic Map
abstract data model. This is not official (yet). Once I'm confident that my
model accurately reflects the topic map design, I'll post it to the HyTime
User's Group Web site (www.hytime.org).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Tue Nov 24 20:44:17 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:42 2004
Subject: ANN: Sample Topic Map
Message-ID: <3.0.5.32.19981124144458.008c71f0@amati.techno.com>

I've placed a sample topic map on the HyTime User's Group site at
<http://www.hytime.org/topicmaps/>.  This map should work with Fujitsu's
latest HyBrick distribution.

This sample demonstrates the Topic Map ideas and demonstrates using Xlink
and Xpointers, in particular, using out-of-line extended links.

Please let me know if you have any difficulties with or questions about the
files.

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Tue Nov 24 21:41:07 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:42 2004
Subject: Expat user group or mailing list?
Message-ID: <3.0.32.19981124121237.01073058@pop.intergate.bc.ca>

At 02:27 PM 11/23/98 -0500, Tom Otvos wrote:
>I know that I am coming across several
>issues that I would not mind airing, such as:
>
>- CDATA sections not sending the correct callback events

Hey, I've been seeing odd corner cases around CDATA sections too...
James?

>- getting the parser to understand high-order ascii characters

What do you mean by "high-order ascii".  If you declare the
encoding as ISO-8859 (or whatever the magic string is) then
I think it works OK, if that's what you mean.  If you're using 
ISO-Latin or some MS codepage and you're *not* providing such
a declaration, expat is going to think you mean UTF-8 and will
properly boot on any characters > 127. 
  -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tomo at pervasive.com  Tue Nov 24 22:15:27 1998
From: tomo at pervasive.com (Tom Otvos)
Date: Mon Jun  7 17:06:42 2004
Subject: Expat user group or mailing list?
In-Reply-To: <3.0.32.19981124121237.01073058@pop.intergate.bc.ca>
Message-ID: <002701be17f7$e18281a0$160410ac@nebula.everyware.com>

>
> >- getting the parser to understand high-order ascii characters
>
> What do you mean by "high-order ascii".  If you declare the
> encoding as ISO-8859 (or whatever the magic string is) then
> I think it works OK, if that's what you mean.  If you're using
> ISO-Latin or some MS codepage and you're *not* providing such
> a declaration, expat is going to think you mean UTF-8 and will
> properly boot on any characters > 127.
>   -Tim
>

James suggested a similar thing.  I suspect that is exactly my problem,
although I have not had a chance to confirm it.  Thanks.

Tom Otvos
Director of Research, Pervasive Software Inc.
"Try not! Do, or do not. There is no 'try'." - Yoda



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Tue Nov 24 23:00:48 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:42 2004
Subject: Topic Maps on SQL
Message-ID: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>

At 10:40 PM 11/21/98 -0600, len bullard wrote:
>Steve brings up the point that I do wish would be looked at 
>seriously by other language communities:  the potential of 
>using property set/grove concepts to create information 
>standards that are independent of lexical/syntax representation 
>and implementation.  

You know, this goes straight to the core of a deep issue.  Where
I have often felt out of sync with the grove/property-set evangelists
is that I perceive syntax as fundamental and any particular
data model as ephemeral.  I guess I must admit that I don't believe in 
"information standards that are independent of lexical/syntax
representation".

The reason is that I know how to interoperate robustly and efficiently
based on syntax; but in my 20 years of experience in software I have seen 
very little successful interoperation based on data structures or APIs;
and usually at high cost and irritating fragility.  This was what
originally drew me to SGML.  Also I have trouble believing that any
one data model will work well across the infinite breadth of application
types and computing infrastructures.  Even one as sophisticated as groves.

Guess I'm just old-fashioned. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 25 00:16:51 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:42 2004
Subject: Topic Maps on SQL
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <365B4BEC.7F59@hiwaay.net>

Tim Bray wrote:
> 
> You know, this goes straight to the core of a deep issue.  Where
> I have often felt out of sync with the grove/property-set evangelists
> is that I perceive syntax as fundamental and any particular
> data model as ephemeral.  I guess I must admit that I don't believe in
> "information standards that are independent of lexical/syntax
> representation".

Fair enough.  OTFOH, is it like DTDs, a matter of when and where 
you use them and for what?  If for the sake of performance, 
clear text based standards must resolve to a binary standard 
(ie, the player only knows how to play a binary), then it may 
be the case that ANY clear text representation works as long as 
the values of the properties expressed are equivalent.  In other 
words, the curly vs pointy bracket debates are only important 
to the loader.  For that situation, what kind of standard 
expression is most useful for the sake of getting agreement on 
the application standard? For many years many of us relied on 
DTDs to do this and it worked pretty well.  Now we have the 
concept of the well-formed (context-free) file.  Because this 
approach is espoused on several lists now, and XML is touted as 
the example, the answers to these questions become more important. 
If answered, it might avoid a lot of work for a lot of people 
for a long time.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Wed Nov 25 00:45:42 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:42 2004
Subject: Topic Maps on SQL
In-Reply-To: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981124183841.0091bd80@amati.techno.com>

At 03:00 PM 11/24/98 -0800, Tim Bray wrote:
>At 10:40 PM 11/21/98 -0600, len bullard wrote:
>>Steve brings up the point that I do wish would be looked at 
>>seriously by other language communities:  the potential of 
>>using property set/grove concepts to create information 
>>standards that are independent of lexical/syntax representation 
>>and implementation.  
>
>You know, this goes straight to the core of a deep issue.  Where
>I have often felt out of sync with the grove/property-set evangelists
>is that I perceive syntax as fundamental and any particular
>data model as ephemeral.  I guess I must admit that I don't believe in 
>"information standards that are independent of lexical/syntax
>representation".

I have said at various times two statements that appear to be contraditory:

1. Syntax standards like SGML and XML are critical to our lives and
   livelihoods
2. Syntax is unimportant

But these statements are contradictory *only if* you consider them in the
same context.  They are not intended to be so considered.

Syntax standards are critical because they provide a reliable mechanism for
data storage and interchange that is both easy to verify and easy to use,
for all the reasons Tim says.  So Tim's belief and confidence in syntax is
both well founded and reasonable.  Without 8879 and XML, we can't ever be
sure if what we have is both correct and complete.  With them, we can at
least tell if what we have is syntactically correct, even if we can't
verify semantic correctness.  Even if we're operating in the
abstractosphere, we can always drop down to syntacta firma to check our work.

But...

Once you enter the realm of semantic processing, that is, applying business
logic to the manipulation of information and knowledge, you are working in
the abstract domain where syntax becomes irrelevant. This is the domain in
which processing standards like HyTime, DSSSL, Xlink, and XSL operate.
Except for SED and AWK, computers do not operate on syntax, they operate on
abstractions derived from syntax.  *As soon as* you parse a document into
elements, attributes, and character data, it is an abstraction. 

To operate on an abstraction reliably over time, you must either own its
definition (because you write the code) or the abstraction must itself be
standardized. When you write a one-off program that takes syntax as input
and does something more than string substitution, you are creating a
private abstraction in your program and then operating on it.  Nothing
wrong with that, but it's important to remember that *there is an
abstraction there*.

If you want to have interchangable and predictable processing on things
like XML documents, there must be an accepted standard for the abstraction
that the processing operates on. Without that, there can be no hope of
predictable behavior because the data is too complex and there are too many
arbitrary choices that can be made about its abstract representation.  In
addition, different types of processing will need different views of the
same fundamental abstraction, so you'll need ways to configure the
abstraction formally.

Both the STEP standard and the grove standard attempt to provide a
standardized framework for defining standardized abstractions.  They were
both independently designed to meet the same requirements: different
software operating predictably on the same data sets.

While I have no great faith in standardized APIs, I do have faith in
standardized data models.  But given a standardized data model, it's much
more likely that a standardized, or at least conventionalized, API for that
data model will appear. And even if it doesn't, it's much easier to adapt
code to different API views of the same data model then it is to different
data models. Thus, even though, for example, SP, GroveMinder, and the DOM
all provide different APIs to access XML groves, it's easy for me to map
all of them into PHyLIS' grove API because the underlying data model is the
same.  My life would be even easier if they all used the same API, but not
*that much* easier, because the cost of managing the API mappings relative
to the total cost of the system is small.

Thus, I think that there is lots value in standardized data models, even in
the absence of standardized APIs.  I think the DOM is useful and good, but
it's not sufficient because it represents a particular set of optimization
and API design choices. By definition, it can never be complete or
completely satisfactory for all tasks for which we might need an API to XML
documents.  So we should *never* expect to have 100% standardization of
APIs even when we do have standard data models.

And any grove or subgrove can always be viewed as a string simply by
providing the appropriate iterator over the nodes, so the syntax is never
far away.

And I should point out that part of the grove standard is a canonical
string representation of a grove (the "canonical grove representation (cgr)
document")  for express purpose of allowing simple string-based comparison
of groves (while you could, in theory, use it for processing, the result is
so verbose as to be silly for that purpose).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From paul at prescod.net  Wed Nov 25 04:19:21 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:42 2004
Subject: Serializations and data structures (was Re: Topic Maps on SQL)
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <365B7EA6.3BE9023A@prescod.net>

Tim Bray wrote:
> 
> You know, this goes straight to the core of a deep issue.  Where
> I have often felt out of sync with the grove/property-set evangelists
> is that I perceive syntax as fundamental and any particular
> data model as ephemeral.  

On the issue of what works and is interoperable in the real world, you are
quite likely right, but on this "chicken and egg" issue of serialization
vs. data model you are not. The serialization only exists to provide for
the longevity of the data. Thus the data model is fundamental and the
serialization ephemeral.

Your argument is that a sentence is more fundamental than an idea, because
the sentence is easier to transmit, record, replay and otherwise
manipulate. But *by definition* ideas are more fundamental than sentences,
because there can only be a sentence after their is an idea, and in the
XML-world, the idea can be reconstructed from the sentence losslessly and
thus lives *at least as long as* the sentence.

Consider the following cases: 

Document A must be published three times. It is encoded now in SGML with
full minimizations. It is sent to the publisher and prints beautifully.
Years pass. RCS SGML is superseded in the organization by XML. The 
document's syntax is changed radically by running it through "sx." But 
the person in charge of the conversion is careful to make sure that the 
grove does not change. They run the print job again: it will print 
beautifully -- and identically -- as long as the formatter is grove 
driven. 10 more years pass. XML fades into oblivion and is replaced by 
the more compact Lisp S-Expression notation (yes, Lisp has finally caught 
on). But the S-Expression notation is designed to be lossless-ly 
compatible with the XML grove, so the software runs off of the grove 
instead of the serealization syntax. The document will print identically 
*again*.

Now what would happen if the formatter were driven directly from the
syntax in each of these cases? It would have broken. Now the usual
syntax-oriented way of handling this problem would be to do a 
transformation from S-Expressions to XML and then to RCS SGML so that
the syntax-driven software can find it. But how do you actually *do*
this translation?

Well, how do you translate from English into French? You take the 
English serialization for the idea, "parse" it back into an idea and
choose a French serialization that preserves the meaning. Meaning 
is king.

Similarly, when we do text transformations, we do something like this:

<tag> -> Element Object -> S-Expr Object -> (S-Expr serialization)

You might avoid creating literal objects, but you can't avoid 
understanding the data in terms of its data model if you don't
want the translation to be lossy. The serializations are 
ephemeral, arbitrary encodings for the underlying data.

> The reason is that I know how to interoperate robustly and efficiently
> based on syntax; but in my 20 years of experience in software I have seen
> very little successful interoperation based on data structures or APIs;
> and usually at high cost and irritating fragility.

I think that what you are really saying is that it is easier to work with
a well-defined serialization (i.e. XML) than a poorly defined API (i.e.
ODBC). Furthermore, XML makes it easy to define serializations (with DTDs)
but there isn't anything as simple but powerful for defining data models.

> This was what
> originally drew me to SGML.  Also I have trouble believing that any
> one data model will work well across the infinite breadth of application
> types and computing infrastructures.  Even one as sophisticated as groves.

There are a few points to make here:

 * the property set paradigm is best described as a meta data-model.
Different applications work with completely different groves constructed
from the same XML document(s). For instance, one could work with the
syntactic grove (e.g. an XML editor). Another would work with the abstract
grove (e.g. a browser) and another would work with the HyTime semantic
grove (e.g. a browser). Yet another would work with a system-specific
grove such as the RDF data model.

 * a complete XML syntactic grove has all of the information in an XML
document. If an XML document provides enough information for you to
accomplish what you need to accomplish, then the grove does too. Of course
building a syntactic grove to pretend it is a character serialization is a
little silly, but the point is that the a complete grove is really
complete.

 * the grove is not the data model to end all data models. It is merely
the foundational model for data from the SGML family of standards. It
makes perfect sense to abstract over that and build Python lists or Java
iterators or a whole other semantic level. If you encode a programming
language in XML, then of course you want a data structure that represents
functions, parameters and classes directly. That may or may not be best
described as a grove.

--

Let me ground my discussion in reality: there are strong sociological and
historical reasons why character-based linearizations are more 
interoperable than binary linearizations. And of course, any transmission
of data between computers will require linearization. So syntax is not
unimportant: but it is a) transient and b) secondary. XML's brilliance
derives from the recognition that something can be transient and
secondary but still very, very important.

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

The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Wed Nov 25 07:24:13 1998
From: wperry at fiduciary.com (W. E. Perry)
Date: Mon Jun  7 17:06:42 2004
Subject: Topic Maps on SQL
References: <3.0.5.32.19981124183841.0091bd80@amati.techno.com>
Message-ID: <365BB081.97DA230D@fiduciary.com>

"W. Eliot Kimber" wrote:

> At 03:00 PM 11/24/98 -0800, Tim Bray wrote:
> >At 10:40 PM 11/21/98 -0600, len bullard wrote:
> >>Steve brings up the point that I do wish would be looked at
> >>seriously by other language communities:  the potential of
> >>using property set/grove concepts to create information
> >>standards that are independent of lexical/syntax representation
> >>and implementation.
> >
> >You know, this goes straight to the core of a deep issue.  Where
> >I have often felt out of sync with the grove/property-set evangelists
> >is that I perceive syntax as fundamental and any particular
> >data model as ephemeral.  I guess I must admit that I don't believe in
> >"information standards that are independent of lexical/syntax
> >representation".

[WEK's finely presented argument snipped, up to the following conclusion:]

> While I have no great faith in standardized APIs, I do have faith in
> standardized data models.  But given a standardized data model, it's much
> more likely that a standardized, or at least conventionalized, API for that
> data model will appear. And even if it doesn't, it's much easier to adapt
> code to different API views of the same data model then it is to different
> data models. Thus, even though, for example, SP, GroveMinder, and the DOM
> all provide different APIs to access XML groves, it's easy for me to map
> all of them into PHyLIS' grove API because the underlying data model is the
> same.  My life would be even easier if they all used the same API, but not
> *that much* easier, because the cost of managing the API mappings relative
> to the total cost of the system is small.
>
> Thus, I think that there is lots value in standardized data models, even in
> the absence of standardized APIs.  I think the DOM is useful and good, but
> it's not sufficient because it represents a particular set of optimization
> and API design choices. By definition, it can never be complete or
> completely satisfactory for all tasks for which we might need an API to XML
> documents.  So we should *never* expect to have 100% standardization of
> APIs even when we do have standard data models.

I think that WEK stops just a hair's breadth short of the necessary conclusion:
each of us, as a user and a comprehender of data, has constructed a uniquely
personal data model and might benefit from accurately expressing that model in
software. At each different computer we use, our personal aggregate data model
constrains the data domain of the system itself:  the data available for
intelligent manipulation are the intersection of data mechanically available to
the system and data structures--culminating in an ontology of
information--understandable to the user. Some significant portion of that data
will depend on distant sources and may usefully be modeled through standard API
mappings. Within a user's local community--corporation, university, political
party, whatever--some portion of that incoming data will by overlaid or
restructured by house standards which may also usefully be expressed in standard
APIs. Separate from this more or less hierarchical redefinition, individual users
also understand data in the light of philosophies, theories, or business
practices to which they adhere but the colleague beside them may not. These
theories too might usefully be modeled in standard APIs--even sold as such by the
gurus who formulate them. Likewise the capability of a particular computer to
handle a particular class of data might be expressed through a similar API.
Limitations of the operating system or, conversely, its particular
capabilities--even the configuration of features of the OS on a given
machine--could benefit (for example, in avoiding common configuration errors) by
being expressed through more or less standardized data models. The abilities of
specialized hardware to handle specialized data types, and the fit between
application software and the data for which it is intended are also clear
candidates for comparable data models. [The MS registry fed by streams of
comprehensible XML and parsed as openly accessible groves!]

The point is that, however necessary it is to produce either standard tagsets or
data models commonly accepted across industries or spheres of interest, the final
indispensable piece is client-side (relative to the incoming data) remodeling of
the standard APIs to the local case. In fact, there will need to be an
overlapping series of these, at enterprise, departmental, user and machine
levels, and also for the interaction of application software with particular data
domains. Personally, I think that this is, par excellence, the role of XML
processors. I also think that building this software obviates the need to wait
for browser support of XML. Instead of waiting to see XML (see ontology?!) we can
be putting data supplied by a growing and worldwide community of publishers to
work in our particular individual contexts, at tasks the suppliers of the data
have no inkling of, and for which they certainly did not mark it up, nor design a
DTD.

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 25 08:52:22 1998
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun  7 17:06:42 2004
Subject: Serializations and data structures (was Re: Topic Maps on
  SQL)
In-Reply-To: <365B7EA6.3BE9023A@prescod.net>
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <3.0.6.32.19981125084549.0092ae00@gpo.iol.ie>

>Tim Bray wrote:
>> 
>> You know, this goes straight to the core of a deep issue.  Where
>> I have often felt out of sync with the grove/property-set evangelists
>> is that I perceive syntax as fundamental and any particular
>> data model as ephemeral.  

[Paul Prescod]
>
>On the issue of what works and is interoperable in the real world, you are
>quite likely right, but on this "chicken and egg" issue of serialization
>vs. data model you are not. The serialization only exists to provide for
>the longevity of the data. Thus the data model is fundamental and the
>serialization ephemeral.
>
I think that is debatable. One could argue that the data model
is the Platonic ideal and the serialization is the real world
realization of that ideal. I guess it depends on what
school of Greek philosophy one favours:-)

>Your argument is that a sentence is more fundamental than an idea, because
>the sentence is easier to transmit, record, replay and otherwise
>manipulate. But *by definition* ideas are more fundamental than sentences,
>because there can only be a sentence after their is an idea, and in the
>XML-world, the idea can be reconstructed from the sentence losslessly and
>thus lives *at least as long as* the sentence.

I would argue that ideas cannot exist without syntax. An idea
pops into real world existence when it is transmitted from brain
to brain. That transmission requires syntax. Without syntax an
idea cannot escape a consiousness.

Case in point: how is the concept of a grove passed from
consiousness to consiousness without syntax?

[Lots of other interesting stuff elided]

</Sean>
if project.TimeAvailable() < project.TimeRequired():
	project.Langauge = "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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 25 09:45:05 1998
From: grove at infotek.no (Geir Ove Grønmo)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps on SQL)
In-Reply-To: <365B7EA6.3BE9023A@prescod.net>
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca> <365B7EA6.3BE9023A@prescod.net>
Message-ID: <GROVE-827lwkf6nn.fsf@tosca.infotek.no>

* Paul Prescod
|  * the grove is not the data model to end all data models. It is merely
| the foundational model for data from the SGML family of standards. It
| makes perfect sense to abstract over that and build Python lists or Java
| iterators or a whole other semantic level. If you encode a programming
| language in XML, then of course you want a data structure that represents
| functions, parameters and classes directly. That may or may not be best
| described as a grove.

Has anyone created an XML property set yet? I recall reading at some
point that someone were working on this, but I've not seen any results
from that yet. If so, where can it be found?

The task of the newly formed XML Information Set Working Group seem to be
similar to the solution provided by property sets and groves. Could
anyone comment on the chances of the WG synchronizing its effort to the
SGML property set?

Excerpts from the XML Activity statement: 

| XML Information Set Working Group 
| 
|  The XML 1.0 Recommendation describes the physical
|  representation of XML documents: the use of brackets, character strings
|  and other "nuts and bolts" which make up the language. The Information
|  Set Working Group is looking at more abstract descriptions of XML
|  documents in terms of document tree structures, elements, their
|  attribute lists and so on. The idea is to provide a common reference set
|  that other specifications can use and extend to construct their
|  underlying data models, thus helping to ensure interoperability among
|  the various XML-based specifications and among XML software tools in
|  general. 

Geir O.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From majayg at iitk.ac.in  Wed Nov 25 10:48:33 1998
From: majayg at iitk.ac.in (Ajay Gangwar)
Date: Mon Jun  7 17:06:43 2004
Subject: Sun's  Xml Library 
Message-ID: <000b01be1860$9abf2de0$52a21090@cse.iitk.ernet.in>

Could somebody please point me to a tutorial / guide on Sun's
XML Library? 

- Ajay Gangwar
  majayg@iitk.ac.in


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Wed Nov 25 12:13:11 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:43 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <00b001be186c$494a4010$7008e391@bra01wmhkay.bra01.icl.co.uk>

>IMHO, set top boxes designed with preconceived program structures will fail
>to attract the interests of production houses and the audience

True if you are thinking of conventional linear programming. False if you
are thinking of interactive information: weather, news, sports results,
programme guides, travel information. If the system is going to process the
data (even just to select and sort it) and not just passively reel it out,
you need a predictable structure that the application understands; and the
application is going to be much more than a simple style sheet.

This is actually causing me a little anguish at the moment. I've suddenly
realised that having an external DTD and a validating parser in place gives
an application no assurances about the structure of the data!

Another example, I feel, of XML being influenced too much by "document"
thinking rather than "data" thinking.

Incidentally we have found people in the media industry very receptive to
the benefits of a clear separation of responsibilities between the designer
of a series (e.g. film/movie reviews) and the author of articles/programmes
within that series. They recognise it as essential to the goal of
"re-purposing" content. We are starting to use XML to control the
organization of some areas of the BBC Worldwide site (www.beeb.com) which we
run, where the disciplines of consistent content structure are now
well-established, without anyone feeling their creativity is impaired.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From larsga at ifi.uio.no  Wed Nov 25 12:25:03 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps on
  SQL)
In-Reply-To: <365B7EA6.3BE9023A@prescod.net>
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>

* Paul Prescod
|
| On the issue of what works and is interoperable in the real world, you are
| quite likely right, but on this "chicken and egg" issue of serialization
| vs. data model you are not. The serialization only exists to provide for
| the longevity of the data. Thus the data model is fundamental and the
| serialization ephemeral.
|
| Your argument is that a sentence is more fundamental than an idea, because
| the sentence is easier to transmit, record, replay and otherwise
| manipulate. But *by definition* ideas are more fundamental than sentences,
| because there can only be a sentence after their is an idea, 

Ideas are definitely more fundamental than sentences (seen as waves of
sound or ink embedded in paper) could ever be. However, the sentence stored 
as a sequence of characters, ideas that are so simple that they remain 
constant for centuries.

When you read the sentence 'All is suffering', would you claim that your
head then contains the exact same idea that Siddharta Gautama (Indian
prince who lived in the 6th century b.c., also known as Buddha) had? In
fact, Zen-Buddhism, a religion that exists specifically to transmit the
experience that this realization led to looks on words with the utmost 
distrust and do not rely on them to transmit the idea.

(The koans that the Zen-Buddhists use in their teaching may seem to
contradict this, but in fact a large part of their function is to break
down the student's reliance on, and faith in, words.)

| Document A must be published three times. It is encoded now in SGML with
| full minimizations. It is sent to the publisher and prints beautifully.
| Years pass. RCS SGML is superseded in the organization by XML. The 
| document's syntax is changed radically by running it through "sx." But 
| the person in charge of the conversion is careful to make sure that the 
| grove does not change. They run the print job again: it will print 
| beautifully -- and identically -- as long as the formatter is grove 
| driven. 10 more years pass. XML fades into oblivion and is replaced by 
| the more compact Lisp S-Expression notation (yes, Lisp has finally caught 
| on). But the S-Expression notation is designed to be lossless-ly 
| compatible with the XML grove, so the software runs off of the grove 
| instead of the serealization syntax. The document will print identically 
| *again*.

This is all based on a hidden assumption: that all tools interpret and
implement the grove model in exactly the same way. Can you really guarantee
that for something as complex as groves for decades? There'll be no
disagreement on the actual sequence of bytes in the files, but their
interpretation in terms of the abstract grove is another thing entirely.

--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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Wed Nov 25 15:06:34 1998
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun  7 17:06:43 2004
Subject: Sun's  Xml Library
References: <000b01be1860$9abf2de0$52a21090@cse.iitk.ernet.in>
Message-ID: <365C2080.96E46DB5@finetuning.com>

http://developer.java.sun.com/developer/earlyAccess/xml/FAQ.html

there's the faq

http://developer.java.sun.com/developer/earlyAccess/xml/examples/index.html

examples

http://developer.java.sun.com/developer/earlyAccess/xml/relnotes.html

release notes

hope that helps....that stuff is kind of buried on the site if you ask
me.  and your still going to have to register to get to it -- which is
also too bad - especially if you're paying by the minute for internet
access -- (which is the case for some of my friends in India).

anyway,  good luck.

lisa rein

http://www.finetuning.com

Ajay Gangwar wrote:
> 
> Could somebody please point me to a tutorial / guide on Sun's
> XML Library?
> 
> - Ajay Gangwar
>   majayg@iitk.ac.in
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From paul at prescod.net  Wed Nov 25 15:11:22 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps onSQL)
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca> <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
Message-ID: <365C1944.74A72CF3@prescod.net>

Lars Marius Garshol wrote:
> 
> Ideas are definitely more fundamental than sentences (seen as waves of
> sound or ink embedded in paper) could ever be. However, the sentence stored
> as a sequence of characters, ideas that are so simple that they remain
> constant for centuries.

So your fundamental argument seems to be that character data is simple and
thus more reliable and long-living. I agree. That's why I use XML.

> When you read the sentence 'All is suffering', would you claim that your
> head then contains the exact same idea that Siddharta Gautama (Indian
> prince who lived in the 6th century b.c., also known as Buddha) had? 

No, I was careful to qualify that *in the domain of XML* we can retrieve
ideas losslessly, because the idea is very simple, and can be defined in
terms of mathematical formalisms.

> This is all based on a hidden assumption: that all tools interpret and
> implement the grove model in exactly the same way. 

Interpret. Yes. Implement? No. As long as the API represents the model
faithfully, the underlying implementation can be whatever it wants. 
(or maybe you mean the implementation of the API must be the same...
that's true). Anyhow, the model is a mathematical formalism designed
specifically to disallow alternate interpretations.

> Can you really guarantee
> that for something as complex as groves for decades? There'll be no
> disagreement on the actual sequence of bytes in the files, but their
> interpretation in terms of the abstract grove is another thing entirely.

Disagreement on the actual sequence of bytes in the files is irrelevant.
If I can't get the moral equivalent of the same grove, ESIS or 
SAX events out of it that the creators intended then I am working with
different data (at the logical level) than they are. The fact that I
have the same bytes is not very comforting if the software that 
processes it fundamentally misunderstands it. ("I think that <HEAD>
is a synonym for <BOLD> and <!-- --> means emphasis.")

XML software can't work with serializations. It must work with the
data model! If that doesn't survive, all is lost. If the data model
a wishy, washy and implicit like that in the SGML and XML
specs, then the data is in danger of mild logical corruption as people
come to understand it differently. "What did Tim mean by this? And 
this?" If it is a well-defined formalism then that danger is much 
smaller (eliminated?).

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

The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Wed Nov 25 15:28:33 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps on
  SQL)
In-Reply-To: <GROVE-827lwkf6nn.fsf@tosca.infotek.no>
References: <365B7EA6.3BE9023A@prescod.net>
 <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
 <365B7EA6.3BE9023A@prescod.net>
Message-ID: <3.0.5.32.19981125091834.007f1100@amati.techno.com>

At 10:44 AM 11/25/98 +0100, Geir Ove Gr?nmo wrote:

>Has anyone created an XML property set yet? I recall reading at some
>point that someone were working on this, but I've not seen any results
>from that yet. If so, where can it be found?

Assuming that you don't accept a grove plan over the existing SGML property
set as the XML property set...

Alex Milowski was supposed to be working on it, but never published it (I
suspect his job duties overwhelmed him).

As XML documents are SGML documents, they can, of course, be represented
using the existing SGML property set. However, it is probably of
significant value to produce a new property set that leaves out all the
stuff XML doesn't need and adds additional properties that reflect
XML-specific semantics, such as name space mappings, PI targets, and the
like.  This will make the property set much easier for the XMl audience to
understand.  But the result should be consistent with the SGML property
set.  In particular, life will be much easier for everyone if a location
address applied to an XML document grove or an SGML document grove will
return the same result for the same input data.  I have no reason to think
that this won't be the case, but it's not guaranteed.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Wed Nov 25 15:28:59 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps on 
  SQL)
In-Reply-To: <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
References: <365B7EA6.3BE9023A@prescod.net>
 <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <3.0.5.32.19981125092808.009af340@amati.techno.com>

At 01:24 PM 11/25/98 +0100, Lars Marius Garshol wrote:

>This is all based on a hidden assumption: that all tools interpret and
>implement the grove model in exactly the same way. Can you really guarantee
>that for something as complex as groves for decades? There'll be no
>disagreement on the actual sequence of bytes in the files, but their
>interpretation in terms of the abstract grove is another thing entirely.

If we can't do this, then I see little hope for the future of humanity
because it means we're all hopeless morons.  It's just not that hard a
thing to do.

First, the fundamental grove model is not that complex: nodes with
properties, a few data types, a three relationship types, and the idea of
"content" and "data" as identified subparts of the larger grove tree.  

Second, the groves produced by different tools can be easily tested by
generating their canonical string representation and comparing them.
TechnoTeacher has already used this technique in testing their GroveMinder
product against the groves constructed by SP.

Third, we can (and must) improve the definition of the SGML grove
construction process to remove any ambiguities there might be (there aren't
many, I don't think, but the definition is not as transparent as I'd like
it to be). This will be one of the main goals of the SGML revision.

Given these three things, I think it's quite likely that grove
implementations will be both provably correct and quite stable for the
foreseable future.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From eliot at dns.isogen.com  Wed Nov 25 16:13:52 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:43 2004
Subject: Using XML-Capable Web Browser Widgets: Part 1 IE5B2 WebBrowser
  Control
Message-ID: <3.0.5.32.19981125101348.009739c0@amati.techno.com>

Ok, enough abstract stuff. Let's do some real work.

Both IE5 and Mozilla now support the direct presentation of XML documents.
This is very cool.  I'm trying to use these new facilities to provide
SGML/XML browsing of groves through PHyLIS and I can't figure out how to do
what I want (or even if what I want to do is possible in the way I think I
want to do it). I thought I'd ask my questions here because it's likely
that someone else may have the same questions and that the answers will be
of benefit to all. I also assume that the relevant technical people track
this list.

Background: how PHyLIS works

PHyLIS (<http://www.phylis.com>) is a generalized system for managing and
browsing groves constructed from any type of data you wish to provide grove
constructors and renderers for.  It provides public classes for grove
constructors and grove renderers, where a grove renderer is an object that
takes a grove as input and produces some useful presentation.

PHyLIS is also a HyTime system in that it provides full HyTime hyperlink
awareness to all grove constructors and renderers. It provides a basic
traversal service such that any grove renderer can determine which of the
nodes it is rendering are linked to anything else and can therefore inform
the PHyLIS server when someone tries to traverse from one of those nodes
(e.g., you click on an element that is linked to something else).  By the
same token, PHyLIS will inform grove renderers when someone traverses to a
node they are rendering.

Thus, a PHyLIS grove renderer must be able to do the following things:

1. Translate user actions against the presented view of the grove into
specific grove nodes. That is, if I click over something, the renderer has
to know what node or nodes that is so it can inform the PHyLIS server of a
traversal initiation action.  Thus a grove renderer has to maintain a
mapping between the data structures used in the rendition and the grove
nodes themselves.  This can be a challenge depending on how the rendition
is actually constructed.

2. Be able to communicate with the PHyLIS server's grove memory to examine
the HyTime link information grove in order to determine if any of the nodes
it's rendering are linked (the HyTime grove provides a list, indexed by
node, of all the nodes that are linked to something).

3. Be able to translate a node into a position or control in the presented
view of the grove in order to reflect a "node traversed to" action.  That
is, when a node is traversed to, PHyLIS will inform the renderer(s) of that
node of the action.  The renderer then does whatever it does (e.g., change
a color, issue a message, scroll to the point, launch a new window, whatever).

This is a pretty simple system that makes it easy to integrate new grove
renderers that have instant ability to participate in all links--no grove
renderer need have any knowledge of any other grove renderer in order to
participate fully in interactive linking.  Because this all happens at the
grove level, the linking is entirely independent of the data types being
linked.

For SGML and XML documents, I want to construct more jazzy renderers then
my current lame tree-view renderer.  It looks like the IE5 WebBrowser
control and the NGLayout control from Mozilla are just the ticket--both are
COM controls, both support the DOM, and both provide high-quality
presentation.

However, I haven't been able to figure out how to integrate these things.
In particular, I haven't been able to figure out how, or if, I can pass a
pre-existing DOM to the IE5 WebBrowser and have it browse it. I expected to
find a "DomRoot" property or a "PutDomHere()" method, but didn't see
anything likely using the class browser in VB5.  I will want to do the same
thing with the NGlayout control, but I haven't gotten it properly installed
yet, so I don't know if there is an obvious way to do it yet.

I can easily use the MSXML control (or its equivalent) to construct a DOM
and wrap PHyLIS' grove API around the result--works great and no
programming difficulty at all.

I think I could also use the WebBrowser control to construct the DOM in its
memory and use that, but when I tried loading an XML document and then
using the DOM-access API, I only found an HTML DOM, not the original XML DOM.

So my questions:

1. Is there a way to pass a pre-existing DOM to the WebBrowser widget?
2. If so, is there way to associate a style sheet (either CSS or XSL) with it?
3. If not, could the IE5 folks consider adding such a facility? I doubt I'm
the only person constructing DOMs outside a browser who wants to then
browse them.
4. Have I missed the obvious and overlooked some natural and easy way to do
what I want?  Is there some secret?
5. Does the IE5 control preserve the XML DOM somewhere when it loads and
renders an XML document?  If so, where is it?

I could serialize my DOM back to syntax, but that would be both egregiously
inefficient and, in the abstract, unnecessary and would loose the
connection between the DOM/Grove in the grove renderer object and the DOM
being presented by the browser widget.

Thanks,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From larsga at ifi.uio.no  Wed Nov 25 17:22:22 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps
  onSQL)
In-Reply-To: <365C1944.74A72CF3@prescod.net>
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
 <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
Message-ID: <3.0.1.32.19981125182127.006c6124@ifi.uio.no>


* Paul Prescod
>
>So your fundamental argument seems to be that character data is simple and
>thus more reliable and long-living. I agree. That's why I use XML.

Then we agree here, at least. :)

[skipping other stuff we agree on]

* Lars Marius Garshol
>
> Can you really guarantee [agreement on interpretation]
> for something as complex as groves for decades? There'll be no
> disagreement on the actual sequence of bytes in the files, but their
> interpretation in terms of the abstract grove is another thing entirely.

* Paul Prescod
>
> Disagreement on the actual sequence of bytes in the files is irrelevant.
> If I can't get the moral equivalent of the same grove, ESIS or 
> SAX events out of it that the creators intended then I am working with
> different data (at the logical level) than they are. The fact that I
> have the same bytes is not very comforting if the software that 
> processes it fundamentally misunderstands it. [...]
>
> XML software can't work with serializations. It must work with the
> data model! If that doesn't survive, all is lost. If the data model
> a wishy, washy and implicit like that in the SGML and XML
> specs, then the data is in danger of mild logical corruption as people
> come to understand it differently. "What did Tim mean by this? And 
> this?" If it is a well-defined formalism then that danger is much 
> smaller (eliminated?).

Well, you can't very well transmit the data model itself between computers
or down through time. In other words: you must have the serialization
syntax. The question is: is an explicit specification of the data model 
of any use?

Tim seems to be saying no, claiming that it is 'ephemeral'.

You + Len + Eliot seem to be claiming that without it the chance that we
don't interpret the syntax the same way is simply too great. 

As the argument stands it looks like checkmate to me. Why not turn the
issue around slightly: what would be difficult to do without the data
model? I can think of one thing: interpreting parts of XPointer 
unambiguously (the string and span stuff, for example) as it and XML 
stand today is near-impossible. A data model would hopefully resolve this.

--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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Wed Nov 25 17:38:27 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps 
  onSQL)
In-Reply-To: <3.0.1.32.19981125182127.006c6124@ifi.uio.no>
References: <365C1944.74A72CF3@prescod.net>
 <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
 <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
Message-ID: <3.0.5.32.19981125113822.00979de0@amati.techno.com>


>Well, you can't very well transmit the data model itself between computers
>or down through time. In other words: you must have the serialization
>syntax. The question is: is an explicit specification of the data model 
>of any use?

Do you mean the definition of the data model or instances of data that
conform to it? If you mean the former, then certainly it can be transmitted
reliably because we have a number of standards for doing so, all based on a
formal representation syntax, including the EXPRESS character syntax,
property set definition documents, etc. (I note that UML currently has no
defined character representation, but they are trying to fix that by
defining an XML representation).

If you mean the latter, again, we have defined serialization mechanisms
that allow the data instances to be reliably transmitted: Part 21 of the
STEP standard, the CGR document for groves, etc. One could even argue, I
think, that persistent CORBA objects that reflect the data model are
reliable transmission vehicles (what is a persistent object but a syntactic
representation of the abstraction the object represents--it might be opaque
if it's binary, but it still has a syntax).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From larsga at ifi.uio.no  Wed Nov 25 18:17:40 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps  
  onSQL)
In-Reply-To: <3.0.5.32.19981125113822.00979de0@amati.techno.com>
References: <3.0.1.32.19981125182127.006c6124@ifi.uio.no>
 <365C1944.74A72CF3@prescod.net>
 <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
 <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
Message-ID: <3.0.1.32.19981125191716.00ab0d68@ifi.uio.no>

* Lars Marius Garshol
>
> Well, you can't very well transmit the data model itself between computers
> or down through time. In other words: you must have the serialization
> syntax. The question is: is an explicit specification of the data model 
> of any use?

* W. Eliot Kimber
>
> Do you mean the definition of the data model or instances of data that
> conform to it? 

Instances of the data model, hamlet.xml, for example. To be really precise 
(as I should have been all along): in-memory instances encoded as electrical
impulses in the memory chips of a particular computer (or a set of computers),
possibly swapped out to disk, but part of runtime memory of a specific 
program.

> If you mean the latter, again, we have defined serialization mechanisms
> that allow the data instances to be reliably transmitted: [actual examples
> snipped]

Let me quote myself: "In other words: you must have [a] serialization
syntax." Whether it is XML or serialized CORBA objects is immaterial, but
you do need a syntax to ensure that the information persists and that you
can transmit it to another computer or program.

So the question remains: do you need an explicit specification of the data
model? 

--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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 25 18:33:10 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:43 2004
Subject: Internal subset equivalent in new schema proposals?
References: <00b001be186c$494a4010$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <365C4359.E2C133E4@prescod.net>

Michael Kay wrote:
> 
> This is actually causing me a little anguish at the moment. I've suddenly
> realised that having an external DTD and a validating parser in place gives
> an application no assurances about the structure of the data!

I don't know what this means.

> Another example, I feel, of XML being influenced too much by "document"
> thinking rather than "data" thinking.

Argh. Documents are data. The dichotomy is in your head. Doesn't XML
itself makes this abundantly clear?

> Incidentally we have found people in the media industry very receptive to
> the benefits of a clear separation of responsibilities between the designer
> of a series (e.g. film/movie reviews) and the author of articles/programmes
> within that series. They recognise it as essential to the goal of
> "re-purposing" content. We are starting to use XML to control the
> organization of some areas of the BBC Worldwide site (www.beeb.com) which we
> run, where the disciplines of consistent content structure are now
> well-established, without anyone feeling their creativity is impaired.

Your two-level system is not sufficient to solve the problem in general.
It ignores the level above "series designer." The world is not structured
in terms of content structurers and structure fillers. Take it from a
"document guy": organizational structures are more complicated than that. 

As an object oriented programmer, this pattern is familiar to you:

A program is a kind of document.
A BBC program is a kind of program.
A BBC television program is a kind of BBC program.
A children's television program is a kind of BBC radio program.
The teletubbies are a kind television program.

It should be possible at every level to 

 a) invent new structures within the bounds imposed from above (above is
"more general")

 b) impose structures on those below (below is "more specific")

IOW, every level needs to innovate and set rules. This is why both you and
Don are right, even if you talk past each other.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Wed Nov 25 18:35:14 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic Maps
  onSQL)
In-Reply-To: <3.0.1.32.19981125182127.006c6124@ifi.uio.no>
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
	<3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
	<365C1944.74A72CF3@prescod.net>
	<3.0.1.32.19981125182127.006c6124@ifi.uio.no>
Message-ID: <13916.18899.623814.794198@localhost.localdomain>

Lars Marius Garshol writes:

 > As the argument stands it looks like checkmate to me. Why not turn
 > the issue around slightly: what would be difficult to do without
 > the data model? I can think of one thing: interpreting parts of
 > XPointer unambiguously (the string and span stuff, for example) as
 > it and XML stand today is near-impossible. A data model would
 > hopefully resolve this.

Fortunately, the XML community already agrees on at least 75% of what
should be in an XML data model (partly driven by past SGML
experience), so the different standards are not so far out of line as
they might be; nevertheless, I assert that the choice is not between
XML syntax or an XML data model, but between an implicit or explicit
XML data model.

Syntax is worthless without a data model; a data model is unusable
without syntax.  If you leave either one unspecified, people will
start inventing their own versions (sometimes with good results, and
sometimes with bad).

Anyway, guys and girls, everyone in every discipline in Western
Civilization has already hashed out this argument in every possible
guise over more than two millennia (Plato vs. Aristotle, soul/spirit
vs. body, transcendentalist vs. materialist, Tennyson vs. Browning,
abstract vs. representational art, classical acting vs. method acting,
PBS vs. Fox, Cultural Studies vs. New Criticism, etc. etc. etc.).  I
was already bored with the arguments when I was an undergraduate; I
think that other cultures must laugh at us.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 25 21:49:50 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:43 2004
Subject: Serializations and data structures (was Re: Topic MapsonSQL)
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
	 <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no> <3.0.1.32.19981125182127.006c6124@ifi.uio.no>
Message-ID: <365C7660.A2833F45@prescod.net>

Lars Marius Garshol wrote:
> 
> 
> Well, you can't very well transmit the data model itself between computers
> or down through time. In other words: you must have the serialization
> syntax. 

You must have a serialization syntax, but they are technically
interchangeable: SGML, XML, S-Expressions, etc. Socially, they are not
interchangeable, of course. If Tim's point was that socially, standardized
syntaxes are very, very important, I would agree with him. I just disagree
when he goes further and says that they are primary.

> As the argument stands it looks like checkmate to me. 

If we've checkmated him, why bother continuing? :)

> Why not turn the
> issue around slightly: what would be difficult to do without the data
> model? 

Luckily I've already got an answer to this question:

---
Understanding an SGML document's structure is easy for simple things, but
there are many issues that are quite complex. For instance, it is not
clear whether comments should be available for a DSSSL spec. to work on,
or whether they should be addressable by hyperlinks. It isn't clear
whether it should be possible to address every character, or only
non-contiguous spans of characters. Should it be possible to address and
process tokens in an attribute value or only character spans? Should it be
possible to address markup declarations? XLink and XSL must solve all of
the same issues.

The problem is that XML is defined in terms of its syntax, just as SGML
was at first. Linking and processing are done in terms of some data model,
not in terms of syntax. When you make a link between two elements, you are
not linking in terms of the character positions of the start- and end-tags
in an SGML or XML entity. You are linking in terms of abstract notions
such as "element", "attributes" and "parse tree". The role of an XML
parser is to throw away the syntax and rebuild the logical ("abstract")
view. The role of a linking engine (such as a web browser) is to make
links in terms of that logical view. The role of a stylesheet engine is to
apply formatting in terms of that logical view.

Unless stylesheet languages, text databases, formatting engines and
editors share a view, processing will be unreliable and complicated. It is
not very common for XML and SGML applications and toolkits to provide all
of the information necessary for building many classes of sophisticated
applications, such as editors. There is not even a standardized way for an
toolkit to express what information from the SGML/XML document it will
preserve. Even if two toolkits preserve exactly the same information, it
is quite possible that they use different structures to organize the
information.

A related problem is how to address components of data types other than
SGML and XML. For instance, how do you make a hyperlink to a particular
frame in an MPEG movie, or a particular note in a midi sequence? How would
you extract that information in a stylesheet (for instance for sequencing
a multimedia hyperdocument). It makes no sense to address in terms of
bytes, because often a single logical entity, like a frame, is actually
spread across several bytes and they may not be contiguous. Addressing in
terms of characters would make even less sense because MPEG movies and
midi sequences are not character based. The web solves this problem by
inventing a new "query language" (in the form of extensions to URLs) for
each data type. This more or less works, but it leads to a proliferation
of similar, but incompatible query languages doing the same basic thing,
but with different underlying models.
---

http://www.prescod.net/groves/shorttut/


 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco
Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From larsga at ifi.uio.no  Wed Nov 25 23:24:34 1998
From: larsga at ifi.uio.no (Lars Marius Garshol)
Date: Mon Jun  7 17:06:44 2004
Subject: Serializations and data structures (was Re: Topic MapsonSQL)
In-Reply-To: <365C7660.A2833F45@prescod.net>
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca> 	 <3.0.1.32.19981125132454.00a78ff8@ifi.uio.no> <3.0.1.32.19981125182127.006c6124@ifi.uio.no> <365C7660.A2833F45@prescod.net>
Message-ID: <wksof7fjcc.fsf@ifi.uio.no>


* Paul Prescod
| 
| You must have a serialization syntax, but they are technically
| interchangeable: SGML, XML, S-Expressions, etc. 

I should come back when I'm awake enough to explain what I mean in
understandable terms, I think. In other words: of course.

* Paul Prescod
|
| If we've checkmated him, why bother continuing? :)

Stalemate! I meant stalemate! (Left my dictionary (and brain) at home.)

| Luckily I've already got an answer to this question:
|
| [answer snipped]

Hmmm. I seem to recall having seen this before?

[From a different email in the same thread:]

* david@megginson.com
| 
| [...] I assert that the choice is not between XML syntax or an XML
| data model, but between an implicit or explicit XML data model.
| 
| Syntax is worthless without a data model; a data model is unusable
| without syntax. If you leave either one unspecified, people will
| start inventing their own versions (sometimes with good results, and
| sometimes with bad).

Thank you for posting this excellent serialization of the thoughts in
my head. Much better than my own previous serialization attempt. :)

| Anyway, guys and girls, everyone in every discipline in Western
| Civilization has already hashed out this argument in every possible
| guise over more than two millennia [...] I think that other cultures
| must laugh at us.

That they don't care about the subjective/objective dichotomy does not
mean that they don't have interminable philosophical arguments. :)

--Lars M. (who doesn't like writing this kind of posting, but didn't
           want to leave people wondering what happened to the
           discussion, 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov 26 00:01:20 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:44 2004
Subject: relation between DOM, SAX, and Schema?
Message-ID: <0e9601be18ce$df80c380$0200a8c0@mdaxke.mediacity.com>

This current thread regarding data vs. API prompts a few
questions I've had for a while.

1. Is the difference between DOM and SAX one of programming
style only (implementation efficiency aside)?
http://www.megginson.com/SAX/event.html seems to say so.
Or is there more to it than "trees vs. events": that SAX
is in the end a driver API that must accomodate anything
a low-level parser wants to offer, while in the end DOM
is a least-common-denominator procedural model for browsers?

2. How does/will metadata affect either?
Once the many XML-based schema proposals (DCD, XSchema, etc.)
are consolidated, when I parse some XML with respect to a schema,
I would like my annotated tree (grove, whatever) to be able to tell me
meta-info about the nodes using that schema (what is its default, is
this optional, what is the description string for this data type
or this element type, etc.). I would like to use the very same API
to ask questions not just about element values, but about the
element metadata as well. It seems that right now neither
DOM nor SAX is ready for this?

-mda





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From srn at techno.com  Thu Nov 26 01:54:19 1998
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun  7 17:06:44 2004
Subject: Topic Maps on SQL
In-Reply-To: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca> (message
	from Tim Bray on Tue, 24 Nov 1998 15:00:39 -0800)
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
Message-ID: <199811260138.TAA01950@bruno.techno.com>


[Tim Bray:]

> You know, this goes straight to the core of a deep issue.  Where
> I have often felt out of sync with the grove/property-set evangelists
> is that I perceive syntax as fundamental and any particular
> data model as ephemeral.  I guess I must admit that I don't believe in 
> "information standards that are independent of lexical/syntax
> representation".

Far from being independent of each other, the interchange syntax and
the grove representation should be two mutually interdependent sides
of the same coin.  Information represented in XML's interchangeable
form is practically useless, but it's easy to preserve and it's highly
interchangeable.  XML information that has been parsed (and converted
into objects, for example) is very useful, but it is platform-specific
and not interchangeable.  Today we have the two sides, but no coin.  A
property set for XML would define, formally and inescapably, all the
relationships between the two sides; it would be the missing coin.

One simple and ineluctible reason why we need a property set for XML
is so that we can know for sure what a node is, so that we can count
nodes, so that XPointers can work reliably.  If the data model of XML
is "ephemeral", XPointers will not work reliably across dissimilar
applications; what an XPointer means will be a matter of opinion.
Unless we know precisely what everybody else regards as the
addressable components of an information resource, we can't reliably
express the addresses of those components.  The grove paradigm and the
property set formalism were developed in order to solve this very
problem, among others, for the SGML family of standards.  

The same intellectual tools will work perfectly for XML, although the
result of a consensus-seeking W3C process might be an XML property set
that doesn't resemble the standard SGML property set very much, if at
all.  But that fact only dramatizes the expressive power of the
property set formalism.  

(And, speaking only for myself, I can face that particular outcome
with equanimity.  It's vital to have a model and to express it so
formally and inescapably that conformance will be easy to verify, and
so that the meaning of an XPointer cannot be the subject of a dispute.
There could be many kinds of differences between the XML property set
and the SGML property set that would not threaten the viability of
XML.)

As I see it, the only alternatives to creating and adopting an XML
property set are:

(1) To create a new formalism pretty much like the property set
    formalism, and to use it to say exactly what the nodes are, and
    which syntactic constructs they correspond to.  I think this is an
    acceptable choice, because the only downside is that some
    redundant work is done.  (It's just another case of "Not Invented
    Here".)

(2) To use EXPRESS to say exactly what the nodes are, and which
    syntactic constructs they correspond to.  EXPRESS is a much
    bigger, much deeper language than the property set formalism, and
    my impression is that it will take only a minor amount of
    adaptation to use EXPRESS for this purpose.  I do not see EXPRESS
    as the solution of "least necessary complexity" for today's
    pressing problems, but I agree with Eliot that EXPRESS or
    something very much like it will ultimately take over for (and/or
    be merged with) the property set formalism.  I think the EXPRESS
    solution is an acceptable choice, because the only downside (if we
    can call it a downside) is that we all have to learn EXPRESS,
    which is a mighty interesting and extremely powerful schema
    language.  (I love the side effects of this particular choice.)

(3) To use some other existing formalism to say exactly what the nodes
    are, and which syntactic constructs they correspond to.  I don't
    know what the candidate formalisms might be.

(4) To formalize no coin, and to continue to have only the two sides.
    This would be to ignore the issue and, most likely, to let the
    biggest honking syndicate on the Internet force its interpretation
    (which it may attempt to keep secret) of what are the classes and
    properties of XML nodes on all of us.  The blackest scenario is a
    war of attrition during which addressing will remain unreliable,
    and after which we will have substantial amounts of legacy data
    that make a lot of off-by-n and other addressing errors.  This is
    an unacceptable and irresponsible choice.  Frankly, I don't see
    how the XLink/XPointers people could possibly ever finish their
    work without a formal model of parsed XML, so I see this as by far
    the least likely choice.

-Steve

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

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 26 02:06:05 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:44 2004
Subject: relation between DOM, SAX, and Schema?
In-Reply-To: <0e9601be18ce$df80c380$0200a8c0@mdaxke.mediacity.com>
References: <0e9601be18ce$df80c380$0200a8c0@mdaxke.mediacity.com>
Message-ID: <13916.46447.515003.90628@localhost.localdomain>

Mark D. Anderson writes:

 > This current thread regarding data vs. API prompts a few
 > questions I've had for a while.
 > 
 > 1. Is the difference between DOM and SAX one of programming
 > style only (implementation efficiency aside)?
 > http://www.megginson.com/SAX/event.html seems to say so.
 > Or is there more to it than "trees vs. events": that SAX
 > is in the end a driver API that must accomodate anything
 > a low-level parser wants to offer, while in the end DOM
 > is a least-common-denominator procedural model for browsers?

An event-based API is the equivalent of a depth-first, LR traversal of 
a tree; a tree can be (re)generated from the events.  The difference
is implementation efficiency, but that's a very big one: an
event-based API makes it possible to process a very large document
using relatively constant resources, but makes arbitrary queries and
transformations difficult; a tree-based API makes queries and
transformations easy, but resource usage increases with the size of
the document.

It is possible to design a tree-based interface that allows partial
processing before the entire tree has been built, but in general,
event-based APIs do a better job of that.  For streaming information
(say, from a real-time news feed or an e-commerce server), event-based 
APIs are probably the only workable choice.

 > 2. How does/will metadata affect either?
 > Once the many XML-based schema proposals (DCD, XSchema, etc.)
 > are consolidated, when I parse some XML with respect to a schema,
 > I would like my annotated tree (grove, whatever) to be able to tell me
 > meta-info about the nodes using that schema (what is its default, is
 > this optional, what is the description string for this data type
 > or this element type, etc.). I would like to use the very same API
 > to ask questions not just about element values, but about the
 > element metadata as well. It seems that right now neither
 > DOM nor SAX is ready for this?

As long as the schema is an XML document (and all current proposals
are), then you can load the document into a separate DOM tree or read
it as a separate event stream.  There will almost certainly be
libraries that will do this for you automatically and let you ask
queries (what is the maximum integer value of a <degrees> element,
etc.).

SAX could also handle this with an additional metadata event interface 
without disrupting existing implementations, but the library approach
seems more flexible.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Thu Nov 26 03:31:02 1998
From: mda at discerning.com (Mark D. Anderson)
Date: Mon Jun  7 17:06:44 2004
Subject: relation between DOM, SAX, and Schema?
Message-ID: <0efb01be18ec$14ca8e00$0200a8c0@mdaxke.mediacity.com>

thanks for the clarification david.

>For streaming information
>(say, from a real-time news feed or an e-commerce server), event-based 
>APIs are probably the only workable choice.

Speaking of which, a month or so ago I was hacking some perl to parse
up a file of xml which in some cases was still being appended to.
I was using XML::Parser, which really seemed to want complete xml
to be parsed (even if it is event based), so I had to slurp in the
file, append a "</root>" to the string, and then parse it.
I still feel unclean.

>SAX could also handle this with an additional metadata event interface 
>without disrupting existing implementations, but the library approach
>seems more flexible.

Yes, in retrospect i can't actually think of a good reason for them
to be joined up. Must have been some after-effect of trying to understand 
SGML groves (http://www.prescod.net/groves/shorttut/). I'm still not
sure whether those give complete access to all DTD info or not; somehow
my brain was not cut out to understand SGML.

I also found a useful message from Ken MacLeod (ken@bitsko.slc.ut.us) to
the perl-xml list, attached here without permission.

-mda

From: Ken Macleod
Subject: Re: Subclassing XML::Parser
Date: Monday, September 07, 1998 4:07 PM
To: perl-xml@lyris.activestate.com

Speaking of styles (this earlier message) and subclassing (the current
thread), and that 2.x ``breaks'' the style that I was using in
XML::Grove, I thought it'd be useful to try to characterize the styles
of interfaces so we have a common ground to talk about.

NOTE: some of these are derivable from the others or mixed styles can
be used, I'm not suggesting any one is ``best''.

In all of these cases, ``caller'' refers to the procedure that
initiates the parsing and receives the events.  These interface
characteristics can generally be applied to both parsers and object
tree traversals.

Generally speaking, we have these types of interface behaviors:

* callback function(s)
  A callback interface is one where the caller passes function or a
set of functions as arguments, and the parser ``calls back'' the
function(s) for each event in the parse.

* callback object or package
  A callback object or package interface is one where the caller
passes an object or a package name and the parser ``calls back'' the
methods on the object or methods in the package for each event in the
parse.

* subclassing the parser
  This is very similar to a callback object interface, except that the
methods called are those of the parser subclass rather than an
receiver object or package.

* event generator
  An event generator is a function or an object that the caller asks
for the next event in the parse, called like this:

   $parser = Parser->new;
   while ($event = $parser->next) { [...] }


With those types of interface behaviors, there are two styles of
arguments:

* an object
  An object event encapsulates the whole event as a single object,
the object may be in a specific class, or a generic object like a hash
or dictionary.

* a parameter list
  A parameter list event passes a list of arguments appropriate for
the type of event, with the type of the event as one of the
arguments.  For a object or package-style callback, the type of the
event is implicit in the method called.


Some common extensions are usually available from the parser directly
or through a helper module.

* tag based
  Callbacks or event generator is based on the name of the tag, rather
than just a generic element.  The event can have either a start/end
flag or there can be different event types for start tags and end
tags.

* conversion to application objects
  The events are gathered to build a complete application object, and
then that application object is passed as the event.

* architectural forms or tag mapping
  This is very similar to tag-based events, except that the tags are
first mapped by a mapping table to another tag set.


Based on these characteristics, here's where I place several current
implementations:

* Larry Wall's XML-Parser-0.0
  A callback interface taking a package name (explicitly as an
argument or implicitly by using `caller') and passing a parameter list
as arguments with the event type implicit in the method name.
XML-Parser-0.0 also supports tag-based events (via the subs package).

* Clark Cooper's XML-Parser-2.x
  A callback interface taking multiple callback functions for event
types, passing a parameter list as arguments with the event type
implicity in the method name.

* David Megginson's SGMLSpm
  An event generator that returns a parse object for each event
generated by the parser.

* David Megginson, et al's SAX
  A callback interface taking an object to receive events and passing
a parameter list as arguments with the event type implicit in the
method name.  SAX is a standardized interface that has implementations
available in Java and Python.

* W3C's DOM
  DOM is an an object tree.  I was going to say it supports an
event generator interface, but it appears to be missing from
the Aug 18 Proposed Recommendation.

* Ken MacLeod's XML::Grove and SGML::Grove
  XML::Grove and SGML::Grove are both object trees supporting a
callback interface taking an object to receive events and passing a
tree object with the event implicit in the method name.  The Grove
modules also support tag-based callbacks.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cbullard at hiwaay.net  Thu Nov 26 05:21:34 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:44 2004
Subject: Serializations and data structures (was Re: Topic Maps
	  onSQL)
References: <3.0.32.19981124141430.00ce2230@pop.intergate.bc.ca>
		<3.0.1.32.19981125132454.00a78ff8@ifi.uio.no>
		<365C1944.74A72CF3@prescod.net>
		<3.0.1.32.19981125182127.006c6124@ifi.uio.no> <13916.18899.623814.794198@localhost.localdomain>
Message-ID: <365CE4D6.3785@hiwaay.net>

david@megginson.com wrote:
> 
> Fortunately, the XML community already agrees on at least 75% of what
> should be in an XML data model (partly driven by past SGML
> experience), so the different standards are not so far out of line as
> they might be; nevertheless, I assert that the choice is not between
> XML syntax or an XML data model, but between an implicit or explicit
> XML data model.
> 
> Syntax is worthless without a data model; a data model is unusable
> without syntax.  If you leave either one unspecified, people will
> start inventing their own versions (sometimes with good results, and
> sometimes with bad).

Wise, David, and thank you.  Please tell me the difference between 
and implicit and explicit XML data model?

Geez.  Ask a simple question and come back to the usual Gorgon's Head 
argument that paralyzes but never gets the job done.  Almost as bad 
as sitting through Cringely's Crummy Tour of Computer History.
Bad.  No wonder Excite and Bill the G have all the money and 
all we have is this "More Meta Than Thou" T-shirt.

The issue:  we have multiple notations for fundamental media types, 
heck, multiple syntaxes. Kinda noisy for the authors.  If content 
is the real king, then making it perform, making it easier to 
author, making it lifecycle-worthy should be on the top of the 
list for the standardsMakers.  OTW, what good are they? (no smiley, 
needed i hope)
 
To operate in this bandwidth-starved email system we use, some 
of the more render-heavy, performance hog media types need to 
migrate away from clear text player formats to binaries.  But, 
hey, everyone out here knows how to compile and *HTML Programmers* 
not withstanding, most of us can accept that.  So far so good.

But clear text is how the humans author for the medium 
in many cases, and if you want to get that content off a 
dead iron horse and onto a shiny new one, it better live 
to make the change.  Dull stuff.  Ought to write a book.
  
I think most of us know that syntax vs data structures is a 
red herring. The APIs have a place as well if you want to 
be able to code to the same framework twice.  No problem. 
When virtual machines grow up and can lift the weight of 
their dads, we'll all use those.  No problem.

XML is a dandy subset of SGML.  Yes, Tim, I think most of us 
were attracted to SGML because we understood that 
markup and a schema are the best way to be both computer and human
friendly 
and to as Charles said, protect information from folks like us.

What we do in SGML we can do in XML just a little easier (no, not a 
lot, a little but every little bit helps).  This is not 
at issue.  However, all the world wide web is not XML 
and may never be.  LISP may someday emerge as the Man 
in The Mask from the prison of obscurity.  Fine, but 
not this week or next.

What is the best way to create clear text standards when the 
clear text is not going in the packets?  Do architectures 
have any advantages over XML DTDs or the schema du jour for this 
kind of application where it may be the case that multiple 
clear text node/property standards have to play on the 
same player?

Extra points for staying on the topic and out of Shakespeare 
and the rest of the legion of Dead Software Society favorites.

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


From creitzel at mediaone.net  Thu Nov 26 06:43:00 1998
From: creitzel at mediaone.net (Charles Reitzel)
Date: Mon Jun  7 17:06:44 2004
Subject: Topic Maps on SQL
Message-ID: <199811260642.BAA10524@chmls05.mediaone.net>

[I'll try to relate this to software...]

Tim Bray wrote:
>
> You know, this goes straight to the core of a deep issue.  Where
> I have often felt out of sync with the grove/property-set evangelists
> is that I perceive syntax as fundamental and any particular
> data model as ephemeral.  I guess I must admit that I don't believe in
> "information standards that are independent of lexical/syntax
> representation".

In general, I have to disagree.  In my experience, applications and syntax
come and go, but the data live on.  Mortgages last up to 30 years, life
insurance policies even longer.  Applications (and platforms!) have about a
3 to 10 year life cycle.  Databases can last much, much longer.  In fact,
databases are frequently converted to/from any number of formats (SQL to
SQL, csv, XML!, xBase, SQL*Loader, VSAM, IMS, WordStar, 1-2-3, ...).  Yes,
this is a pain in the neck - but not the biggest one.  The logical
relationships in the data are what determine if you can "get there from here".

Getting back to SQL for a moment, I think it is important to remember that
SQL specifies a few things: a handful of attribute data types, the
definition of entities as a fixed set of attributes and a set of operations
that can be performed on entities and attributes.  This last part is perhaps
the most important as the first two are trivial.  Because of the simplified
data types and relationships, a set of highly general operations can be
defined: sorting, searching, set operations, etc.  Network databases add
direct entity set relationships and navigation to the mix.  With relational
databases, all such relationships are ad hoc based on attribute values
(which is often a requirement).  No such base set of operations exists for
object databases.  Object databases provide great behavioral flexibility,
but you give up some of the power of the standard operations.

>From Paul Prescod's "Introduction to Groves and Property Sets":
>
>You can think of the grove as a meta-"data model" for media 
>applications. It is a data model for building data models. Or you 
>could think of it as providing the low-level primitives for 
>building high-level, media-specific models.

At first glance, Groves look like the DOM for SGML.  Is this right?  In
which case it can pretty much represent XML.  Certainly, it has sufficient
syntactic "degrees of freedom" to describe SQL entities and attributes, if
not SQL operations.  But I'm not sure what this buys you.  I certainly don't
see how you build a potentially large database of abstract nodes and
properties and query and update it.

I also didn't quite get from the intro *how* Groves can express links to a
frame in an MPEG video, a measure within a MIDI sequence or any other
arbitrary media as it intimates it can (the "intrinsic" properties seem SGML
oriented).  Depending on your document base, this capability might be an
important operation missing from standard SQL (although there are a number
of proprietary solutions available off the shelf).  Such a syntax would
eliminate one problem in the example I posted previously.  Things
participating in an association might not have to use generated sequence
numbers.  More general expressions could be used instead.  I'm not sure what
it looks like, though.

To summarize, I didn't think the problem was how to express links to XML or
SGML.  But rather, how to use XML to express and collect links to SQL, to
video, to VRML, to audio, to MIDI, and so forth?  The more I think about it,
document descriptions, authors, dates, publishers, and a collection of MIME
headers and a URL/HREF will do pretty well.  All of which is highly doable
using a SQL/Network database to emit XML w/ DTD.  Anything much fancier
probably needs OODBMS.

Regards,
Charles Reitzel
creitzel@mediaone.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 26 10:11:39 1998
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:06:44 2004
Subject: SAX in C++?
In-Reply-To: "Tom Otvos"'s message of "Tue, 24 Nov 1998 11:35:17 -0500"
References: <002201be17c8$6b61c460$160410ac@nebula.everyware.com>
Message-ID: <3916.199811261011@mcilvanney.cogsci.ed.ac.uk>

"Tom Otvos" <tomo@pervasive.com> writes:

> Are there any efforts underway to do a C++ version of SAX?  I know that
> because of the dynamic class loading of Java, the C++ version would not be
> as "functional" (short of requiring CORBA), but the motivation for having a
> standard API to XML parsers is the same.

We will probably include approximate SAX and DOM interfaces on top of
our C API in the next release of LT XML [1], but I can't say when that
will be.

ht

[1] http://www.ltg.ed.ac.uk/software/xml/
-- 
  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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rbourret at ito.tu-darmstadt.de  Thu Nov 26 11:05:50 1998
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun  7 17:06:44 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <01BE1934.641C90A0@grappa.ito.tu-darmstadt.de>

Paul Prescod wrote:

> Argh. Documents are data. The dichotomy is in your head. Doesn't XML
> itself makes this abundantly clear?

Documents might be data, but the dichotomy is not just in our heads.  XML 
has a clear bias towards linear, prose-oriented verbiage.  How else to 
explain mixed content, the significance of order (as opposed to nesting), 
and the lack of basic data typing?  Fortunately, XML is proving itself to 
be a good way to transport the kinds of data many of us think of when we 
hear the word "data".

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 26 12:33:39 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:44 2004
Subject: Internal subset equivalent in new schema proposals?
References: <01BE1934.641C90A0@grappa.ito.tu-darmstadt.de>
Message-ID: <365D4673.7BECDE36@prescod.net>

Ronald Bourret wrote:
> 
> Paul Prescod wrote:
> 
> > Argh. Documents are data. The dichotomy is in your head. Doesn't XML
> > itself makes this abundantly clear?
> 
> Documents might be data, but the dichotomy is not just in our heads.  XML
> has a clear bias towards linear, prose-oriented verbiage.  How else to
> explain mixed content, the significance of order,

I find it interesting that you use the fact that XML supports things that
other languages do not evidence of XML's bias. Java must be biased towards
Asians because it supports Unicode. 

I use this analogy for a reason: XML's strength comes from the fact that
it solves the *whole problem* and not just the tiny quarter of it that
would make relational database people happy. It turns out that the
problems of structuring relational data are so incredibly simple to solve
that all of their problems are subsumed in the problem of modelling
documents. After all, relational data regularly finds it way into
documents: look at a telephone book or parts catalog. I would trust Asians
to invent character sets more than North Americans because our problems
are a subset of theirs!

> (as opposed to nesting),

XML supports nesting nicely!

> and the lack of basic data typing?  

There are two myths here: that SGML does not support data typing (which it
has, explicitly, since 1986 and in another sense, since 1992), and that
document people do not care about data typing.

XML provides basic data typing. Data typing is provided at the element
level. Sub-element data typing is supposed to be provided by applications
and triggered by notations. This is generalized (like everything else in
SGML) because we all have different needs, and it seemed an easy enough
thing to add in another layer. You might not like these design decisions,
but they were design decisions and not things that the designers left out.

So called data-typing is something that people from document backgrounds
*regularly ask for*. "Please allow us to force our users to make
phone-numbers phone-numbers and dates dates", they beg. If you go back in
the archives of various obscure mailing lists, you'll hear me asking this
question five years ago, and without a relational or OO database in sight!

Dejanews seems to only go back to 1995 for comp.text.sgml, but you'll see
the question asked there almost immediately:

http://www.dejanews.com/getdoc.xp?AN=110985505

Even if you don't believe me that document people care about things like
phone numbers, dates and other regular forms, consider this: how much do
you think it would be worth to a technical publication director to be able
to stipulate that empty paragraphs are illegal? To me, this is just
another lexical constraint, and is not much different from requiring a
valid credit card number.

The powers that be made the decision in 1986 that the notation mechanism
allowed users to implement their own solutions, in some cases based upon
other ISO standards. Later, they came up with a standard lexical-typing
mechanism to this problem around 1992. It's a little ugly, so I don't
blame the W3Cers for wanting to do it themselves, but nevertheless it
exists. It is an add-on to SGML called HyLex. It isn't a mandatory part of
an SGML system, so people can still invent their own solutions if they
want. Later, they extended it to allow Posix regular expressions also.

http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.2.1.html
http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.2.3.html

It is debatable whether lexical typing and data typing are the same. But
it is similarly debatable whether it is the responsibility of a *language
definition language* to enforce constraints that can not be expressed in
terms of linguistic formalisms. It isn't a question of "documents vs.
data" but "whose job is it?" There are many sorts of document-oriented
constraints that SGML also cannot express without add-ons.

> Fortunately, XML is proving itself to
> be a good way to transport the kinds of data many of us think of when we
> hear the word "data".

Of course...SGML has been doing so for years.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Thu Nov 26 14:17:47 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:44 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>

>> > Argh. Documents are data. The dichotomy is in your head. Doesn't XML
>> > itself makes this abundantly clear?...
>>
>> Documents might be data, but the dichotomy is not just in our heads.  XML
>> has a clear bias towards linear, prose-oriented verbiage.  How else to
>> explain mixed content, the significance of order, ...
>
>I find it interesting that you use the fact that XML supports things that
>other languages do not [as] evidence of XML's bias...

A document is information organised for human communication; data is
information organised for machine processing. XML can do both, but I stick
with my original claim that it is optimised for the former.

I wasn't complaining that it contains many redundant features which would
not be there in a data-oriented syntax. I have learned not to use those
features, and I try to explain patiently when people ask yet again whether
they should be using elements or attributes...

Rather my complaint was about things that I'd like to do in the data
interchange world but can't. As Ron says, I can't do data typing in XML 1.0,
and Paul's explanation doesn't alter the fact.

The complaint in my original post was my recent discovery that the internal
DTD subset destroys many of the assumptions I have made in my applications
about the conformance of the incoming document to a schema.  Specifically:

- if I'm quite clever with my EntityResolver I can ensure that the input XML
uses a particular external DTD
- if I choose, I can ensure that my application uses a validating parser
- but I can't stop the input XML using an internal DTD subset which
overrides declarations in my external DTD, nor can I (using SAX) detect that
it has done so.
[ - so my application must be prepared for anything
  - so my application has to do full validation itself
  - so there's not much point having a DTD in the first place ... ]

Actually, the problem is not quite as bad as this: the internal DTD subset
can override constraints in my attribute declarations but not in my element
declarations. Let us be thankful for small mercies. This seems to be another
reason for using elements rather than attributes, which I will add to my
standard answer on the question: the very limited data typing available for
attributes can be overriden at the whim of the user!

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Thu Nov 26 15:55:06 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:44 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <13917.30241.570011.273728@localhost.localdomain>

Michael Kay writes:

 > Rather my complaint was about things that I'd like to do in the
 > data interchange world but can't. As Ron says, I can't do data
 > typing in XML 1.0, and Paul's explanation doesn't alter the fact.

XML is a metalanguage for defining markup languages: in the markup
languages that you define with it, you can do any sort of data typing
you want:

<class id="person">
  <name>Person</name>
  <inherits-from>Object</inherits-from>
  <member type="primitive">
   <name>name</name>
   <type>string</type>
   <max>24</max>
  </member>
  <member type="primitive">
   <name>age</name>
   <type>int</type>
  </member>
</class>

<object class-id="person">
  <member name="name">David Megginson</member>
  <member name="age">34</member>
</object>

<object class-id="person">
  <member name="name">Tess Megginson</member>
  <member name="age">3</member>
</object>

Your complaint is not that XML does not support data typing, but that
generic XML parsing tools do not enforce the kind of data typing that
you need out of the box.  One of the reasons for this is that
everyone's requirements are different; I might want

  <name type="city">Kingston</name>

where the type is enforced to be the name of a city that is currently
in my database.  Someone else might want

  <subject type="LC">BS</subject>

where the contents must be a Library of Congress subject.

That said, many people believe that there might be a small set of
data-typing primitives that have enough usefulness that they should be
standardised across all XML implementations rather than being defined
separately for each XML-based markup language.  As Paul (I think) has
pointed out, the document people can use these just as easily as the
data people can.

By the way, the XML 1.0 spec does include at least one data-typing
attribute, 'xml:lang'.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 26 17:12:50 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:45 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <001501be1960$3180c4f0$28f96d8c@NT.JELLIFFE.COM.AU>

 From: Michael Kay <M.H.Kay@eng.icl.co.uk>

>A document is information organised for human communication; data is
>information organised for machine processing. XML can do both, but I stick
>with my original claim that it is optimised for the former.

PDF is a better example of  information organized for optimal human
communication. A "publication" is information organized and optimised for a
particular use. A document can be published as PDF for humans, or in binary
for some computer, or in XML for both (or neither, which seems to be what
you are saying).

>Rather my complaint was about things that I'd like to do in the data
>interchange world but can't. As Ron says, I can't do data typing in XML
1.0,
>and Paul's explanation doesn't alter the fact.

XML is not a "data exchange language" but a "data markup language". More
than
ASCII, less than serialization.

Attribute types are IMHO fundamentally not geared to data typing but to
marking up structures:
    1) link anchors to elements or entities or notations
            (ID, IDREF, IDREFS, ENTITY, NOTATION)
    2) link anchors that can be used for other XML names, like attribute
values
            (NMTOKEN, NMTOKENS)
    3) err, everything else
            (CDATA)

Thus the attribute types are really only concerned with marking up other
structures within XML. Apart from CDATA you can say that in fact all XML
attribute typing is to aid the markup of  links internal to a document.

NMTOKEN can be explained as a way to catch both references to XML names and
as a way to allow tokens which do not conform to full ID syntax to be used
as ids (i.e. when people mark up a document using simple numbers as the
convention for forming the unique identifiers for elements). IMHO the fact
that NMTOKENS provides a nice way to stick other tokens in is purely a happy
accident, and not a serious attempt to provide any kind of better data
typing.

So rather than saying that XML provides only limited built-in data types for
attributes, I think it is fairer to say that XML provides *ABSOLUTELY NO*
data types. The typing that is present is there for marking up structures
(not data values per se) and making connections between nodes: for internal
links, not for data typing.

Should XML provide better data types? I would say no: not in the XML 1.0
spec.

Should XML provide better support for other data typing layers (schemas)? I
would say yes: the notation idea should be clarified (I really think the SIG
and some of the WG did not have much idea what it was for when the spec was
made: in particular the relation between MIME content types and notations
should have some policy made: is a notation a name which some script uses to
key code or is the address of code which should be downloaded and run?) and
the WebSGML "DATA notation" attribute should be introduced: it lets you add
any notation name to any attribute:
    <!NOTATION iso-8601-date SYSTEM "ba;h blah">
    <!!ATTLIST x
            z DATA iso-8601-date #REQUIRED >
I think this is needed so that attributes and elements are more
interconvertable.

>I wasn't complaining that it contains many redundant features which would
>not be there in a data-oriented syntax. I have learned not to use those
>features, and I try to explain patiently when people ask yet again whether
>they should be using elements or attributes...

If you do not use them, it is presumably because you do have the particular
kinds of convoluted links in your data. If you find you only use CDATA, it
is a sign that your data is nicely tree structured without need for
graph-structures (ID/IDREF) or multiple links to external resources (ENTITY)
or you don't need to add data-typing to elements  (NOTATION) or references
to element type names, attribute names, or enumerations in attribute values
(NMTOKEN).

These are not redundant, in fact they are orthogonal and rational.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 26 18:15:16 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:45 2004
Subject: Internal subset equivalent in new schema proposals?
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <365D9630.A46F3D2D@prescod.net>

Michael Kay wrote:
> 
> A document is information organised for human communication; data is
> information organised for machine processing. 

SGML and XML are explicitly about organizing information for machine
processing. So according to your definition, SGML is about data, not
documents.

> XML can do both, but I stick
> with my original claim that it is optimised for the former.

I can't stop you from sticking to your claim, but I do ask that you
replace your repudiated arguments with new ones.

> I wasn't complaining that it contains many redundant features which would
> not be there in a data-oriented syntax. I have learned not to use those
> features, and I try to explain patiently when people ask yet again whether
> they should be using elements or attributes...

Could you please describe how it is important that a document-oriented
language have both elements and attributes, but not a data-oriented
language? It may be convenient to attribute (excuse me) everything that
seems strange or wrong about XML to this false cultural dichotomy, but it
doesn't hold up to analysis. "Document people" don't understand the
distinction between elements and attributes either. (or if they do, nobody
has told me) We discussed removing them in the move to XML, but it was
decided that they were a typing and programming convenience and provided
simple lexical typing.

If you want to claim that XML is biased towards human *creation* (not
consumption) then I will strongly agree. IF it were not for human factors,
we could have defined a much more compact, portable, binary encoding.

> Rather my complaint was about things that I'd like to do in the data
> interchange world but can't. As Ron says, I can't do data typing in XML 1.0,
> and Paul's explanation doesn't alter the fact.

That "fact" is arguable. But even if we accept it, you haven't
demonstrated how it has anything to do with XML's roots in document
processing instead of "data processing?" You just assert it.

As far as the fact goes: you are right, you cannot do data typing in XML
1.0 alone -- you must reference some other standard like ISO 8601 or
HyTime Lextype. You also can't do hypertext linking in XML 1.0 alone.
Would you argue that "document people" don't do hypertext linking and
that's why it isn't built in?

You *can* do data typing in one of four standardized ways I've described
already: content models, NOTATION, LEXTYPE and HYLEX. So this problem was
solved in the document community either 10 or 6 years before XML came
along, depending on how you count it, but document-centricity still takes
the blame that XML doesn't support it? The logic doesn't jive.

> The complaint in my original post was my recent discovery that the internal
> DTD subset destroys many of the assumptions I have made in my applications
> about the conformance of the incoming document to a schema.  

Document people have been complaining about this problem since before
there was an XML also. Eliot Kimber (a "document guy") has expounded on
this issue in this very forum and in comp.text.sgml.

http://www.oasis-open.org/cover/n1957Note.html

This is just as big a flaw for document people as it is for data people. I
know that it is natural to try to and find reasons for flaws, but
sometimes things are just wrong. There is no cultural reason for them. I
guess that if it were really important to blame someone, I would have to
blame the computer scientists who could not see that documents were data
and thus left it to a lawyer to solve the generalized problem of
character-based data representation. Compounding the mistake doesn't solve
anything.

Of course, "document people" must take most of the blame for SGML's flaws,
because it clearly came out of the document processing community. But it
doesn't logically follow that document people have different needs from
everyone else. We have a superset of everyone else's needs. Any sort of
data can end up in some document and we must be able to handle it.

> Actually, the problem is not quite as bad as this: the internal DTD subset
> can override constraints in my attribute declarations but not in my element
> declarations. Let us be thankful for small mercies. This seems to be another
> reason for using elements rather than attributes, which I will add to my
> standard answer on the question: the very limited data typing available for
> attributes can be overriden at the whim of the user!

It was only in the change from SGML to XML that it became possible to
override attributes from the internal subset. You would have to blame the
"web people" for that change, I guess. Old SGML didn't have that
particular problem.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Thanksgiving in November? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Thu Nov 26 19:29:06 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:45 2004
Subject: Internal subset equivalent in new schema proposals?
Message-ID: <009701be1972$5a2f0670$7008e391@bra01wmhkay.bra01.icl.co.uk>

>I wrote:
>> A document is information organised for human communication; data is
>> information organised for machine processing.
>
While Paul Prescod asserts:
>SGML and XML are explicitly about organizing information for machine
>processing. So according to your definition, SGML is about data, not
>documents.

Well, I know that SGML folks have always seen SGML as the solution to
everything, but I don't think they've erased the evidence of where it came
from, which was device-independent typographical markup.

If you were to design something for processing data (not just rendering it),
you'd have support for the kind of data models recognised in the database
world; you'd have integrity constraints (including data types and primary
keys); you'd have declarative query languages and report writers rather than
navigational APIs and style sheets; you'd have relationships rather than
hyperlinks; and (to be trivial about it) you'd have examples in the domain
of customers and orders, not books and poems.

It so happens that XML is better for doing application-to-application data
interchange than things (like ASN.1) that were supposedly designed for the
job, so I don't begrudge it. But XML (including its friends and relations)
is full of things that wouldn't be there if that were its original primary
purpose, and I really don't see how one can claim otherwise.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From bryan.cooper at veritas.com  Thu Nov 26 20:27:55 1998
From: bryan.cooper at veritas.com (Bryan Cooper)
Date: Mon Jun  7 17:06:45 2004
Subject: Nested schemas
In-Reply-To: <365C4359.E2C133E4@prescod.net>
References: <00b001be186c$494a4010$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <199811262027.MAA01719@mailhub1.ncal.verio.com>

I am just starting with XML and appreciate this list.  Here's my
first 2 cents worth (ISDN dial up means it probably costs .003434 cents
except for the wasted time connecting)

I have some background with databases and text processing (troff project in
1982-
1984  and Tex in 1986-1988) and also distributed SQL databases (1988-1994)
and 
so I thought that XML has some very interesting features.  I am not sure where
some of the discussion on this list regarding semantics or theoretical
stuff is going to go but hey go for it if it helps your projects or the
language.

My take on XML at this stage is that it solves an age-old problem
for coding - the parser.  Its really a drag building ASCII/TEXT oriented
parsers for small utilities and the like.  So, first off XML is a generic
parser without YACC or more cryptic tools some of us have
scratched our heads over.

Some applications take parsers better than other.  That's just a fact
of information as far as my own personal experience has shown.   If
true, then XML is going to be more quickly adopted by applications which
in fact already have parsable information, such as HTML based, and
which are designed for one single function, such as displaying information.

In terms of nested schemas, a point to point type application, such
as one client - one database server, is probably going to be easier to use 
XML than  a distributed, multi-node application which requires integrating
several data sources simultaneously.  Embedding different types
of data from one app within other types of data from other apps
works better/easier for specific tasks such as displaying that data 
(HTML or other tagging document approaches)  
than it does for open-ended manipulating that data.  The reason is
we are ASSUMing that the data from different sources has 
some interrelationships with each other.

The reason it works well for display is that we're really only concerned
at this point with ONE application - the display of the information
from multiple sources.  Most applications know at least how to display
information, so that is a lowest common denominator function amongst many
many apps.

We really are not asserting that the information
is even coming from multiple sources - multiple physical locations,
sure under web approach.  But the generator of the information could
be just one application as far as the display application is concerned,
and its role is one specific task.  Other tasks like hyperlink are relatively
simple extensions to the display (here it comes) paradigm.   

Manipulating the information from multiple applications is a
huge step, since applications are still in their infancy 
regarding inter-relationships.  To this line of thinking,
using XML in the case of complex documents from multiple
applications is "merely" the formalization of the inter-relationship between
those applications. 

When and if there IS such an inter-relationship, it could be asserted that XML
would prove the formal rules do in fact apply and the inter-relationship
is proven.  If we are stating we want to create that inter-relationship
and XML is the method of externalizing that inter-relationship, then
that's a good first step.  Externalizing information relationships isn't
new to
information models but it also isn't easy.  Object models appear to
be more flexible but they still take a lot of work to be effective.

Any technique is inherently limited since we are formalizing something 
that may never have been formalized previously.  That doesn't mean 
the technique is inadequate - but it does mean the technique brings some
constraints that must be reflected somewhere - usually back in
the applications using the technique.  Nothing wrong in that.

So, where does that leave us with 'nested schemas'.  The first issue
I see is that the syntax may overlap between applications.  How
do we deal with that 'cause long term that will make XML a dead end for
anything like the lingua franca that some proponents are calling this
approach.  
The reason is that application development is still primarily done for
specific tasks and business issues  - the need to cross-boundaries
should be made easier by XML.  However, XML must then have
very simple techniques to support the different information models
it is parsing.

How do we ensure the parser is told to switch between 2 or more
different information parsers which use some common words in different
ways?  I think there's a need to resolve this issue - course I may have
missed the easy way to do that.    

I think there's enough brainpower out there to solve something
as basic as this.  If there are proposals already out there, can someone
summarize them with pointers to their design?  

My personal interest is in the combination of parseable information with
command driven applications.  CLI type utilities are prime candidates
for XML 'cause we can use XML syntax to join the CLI commands with the 
information required to be processed by the CLI.

XML doesn't directly support an event driven application syntax.
To my mind, it would require built-in XML event blocks for the parser so that
the parser could in fact be data-driven to interoperate with the application
more easily.  I see the parser currently as query driven from the application,
where the parser is expected to read in a "document" as one block and then
it is broken down into the tagged components.

It would be interesting to see how XML could be used instead to
inter-operate between the parser and the application where there were
staged parsing based upon information within the information.
This extension would need to be supported in the DTD so people
could easily tell the XML parser when and where to breakdown the
information.  

In general, XML enhancements need to focus on how to improve the
parser.  We need more than ELEMENTS and ATTRIBUTES as fundamental
parser controls if the basic parser is going to be improved to support
a wider range of applications.  I'd like to see EVENTS discussed in relation
to nested schemas for example to help the parser switch schemas.   
We need to look as whether issues like  nested schemas is really leading us 
toward something more powerful for the  parser and therefore more helpful to 
alot more applications.

Thanx and I look forward to reading more about specific XML application
development problems.

...bryan

F. Bryan Cooper	 		707 823 7324 
VERITAS Software      		707 321 3301 mobile
Bryan.Cooper@veritas.com   

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From murray at muzmo.com  Thu Nov 26 21:00:58 1998
From: murray at muzmo.com (Murray Maloney)
Date: Mon Jun  7 17:06:45 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: <009701be1972$5a2f0670$7008e391@bra01wmhkay.bra01.icl.co.uk
 >
Message-ID: <3.0.1.32.19981126160110.00947ea8@pop.uunet.ca>

At 02:24 PM 11/26/98 -0500, Michael Kay wrote:
>
>Well, I know that SGML folks have always seen SGML as the solution to
>everything, but I don't think they've erased the evidence of where it came
>from, which was device-independent typographical markup.
>
Sheesh! I can almost see you spitting out these words.

Let me remind you that UNIX came out of Bell Labs
because their lawyers needed an operating system
on which they could create their patent applications.
The troff/pic/eqn/grap/awk/sed/... family of tools
were created for document processing.

So, if you want, you can blame/credit lawyers and document
creators with both UNIX and SGML. And so what?

UNIX is also missing a lot of stuff. That is the beauty
of UNIX isn't it? It is a system on which one can build.
As Brian Kernighan is quick to point out, UNIX can be 
easily extended through "little languages".

So, rather than this constant, annoying, and whiny rhetoric,
it might be worthwhile to note what XML is good for and 
to contribute to building upon it. To wit, see SOX.

Oh, and one more thing, technology is not self-sufficient.
"Document people" have been a principal consumer of 
computer technology for many years, and technologists
might count themselves lucky that document people haven't 
treated technologists with as much contempt as they --
the customers -- have been subject to. Harumph!

Regards,

Murray






Murray Maloney, Esq.          Phone: (905) 509-9120
Muzmo Communication Inc.      Fax:   (905) 509-8637
671 Cowan Circle              Email: murray@muzmo.com
Pickering, Ontario 		Email: murray@yuri.org
Canada, L1W 3K6    		

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From James.Anderson at mecomnet.de  Thu Nov 26 21:08:20 1998
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun  7 17:06:45 2004
Subject: Internal subset equivalent in new schema proposals?
References: <001501be1960$3180c4f0$28f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <365DC398.F233BE62@mecomnet.de>

Rick Jelliffe wrote:
> 
> XML is not a "data exchange language" but a "data markup language". More
> than
> ASCII, less than serialization.

A narrower classification would be more accurate. As Mr Jelliffe illustrates
later in his note, since the descriptive capacity of XML is limited to
internal properties, XML is not even a "markup language", but rather a "markup
encoding". The difference is significant in that, once one acknowledges this
fact, any demands that the standard describe semantic properties of the
encoded data no longer even make any sense. It also becomes appearent that
successive layers are the way to go and the problem becomes much easier to handle.
> 
> Attribute types are IMHO fundamentally not geared to data typing but to
> marking up structures:
>
> ...
>
> So rather than saying that XML provides only limited built-in data types for
> attributes, I think it is fairer to say that XML provides *ABSOLUTELY NO*
> data types. The typing that is present is there for marking up structures
> (not data values per se) and making connections between nodes: for internal
> links, not for data typing.
> 
> Should XML provide better data types? I would say no: not in the XML 1.0
> spec.
> 
> Should XML provide better support for other data typing layers (schemas)? I
> would say yes: ....


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Fri Nov 27 04:03:14 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:45 2004
Subject: Nested schemas
Message-ID: <000e01be19bb$259fc900$4df96d8c@NT.JELLIFFE.COM.AU>


From: Bryan Cooper <bryan.cooper@veritas.com>

>How do we ensure the parser is told to switch between 2 or more
>different information parsers which use some common words in different
>ways?  I think there's a need to resolve this issue - course I may have
>missed the easy way to do that.

This is what the "Namespaces" proposal is about: a way to combine fragments of documents which may use the same words. The approach
is basically to say that every name (i.e. element type name or attribute name) actualyl has two parts: first the name as used in the
originating document, second the name of the namespace to which it belongs.

See www.w3.org/TR in the drafts section for details. The new draft is fairly clear I think. (Except for the Appendix...what a messy
idea!)

>It would be interesting to see how XML could be used instead to
>inter-operate between the parser and the application where there were
>staged parsing based upon information within the information.
>This extension would need to be supported in the DTD so people
>could easily tell the XML parser when and where to breakdown the
>information.

XML does support a kind of  staged parsing, through the NOTATION mechanism. When you give an element a NOTATION attribute, you are
informing some later stage to interpret the contents of the element using the correct processor for that notation. This is how to
embed non-XML notations. (Note: this is not switching between notations: it is the foreign notation in XML, not stopping XML rules
and switching to the different rules.)

> I'd like to see EVENTS discussed in relation
>to nested schemas for example to help the parser switch schemas.

There already is another thing which is not elements or attributes, and I think it corresponds to what you are calling EVENTs: the
processing instruction allows any kind of non-structural (that is element structure) information to  be instered at points during in
the document. The XML header is one such processing instruction.

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


From xmldoubts at hotmail.com  Fri Nov 27 07:33:13 1998
From: xmldoubts at hotmail.com (Prashanth K. Salur)
Date: Mon Jun  7 17:06:45 2004
Subject: Sun XML Lib
Message-ID: <19981127073159.21022.qmail@hotmail.com>

Hi All,

I guess some one can solve my problem

If the Xml File is in the local directory to parse it we will write 
something like this (Given in SunXML lib examples)
....
String uri = "file:" + new File (argv [0]).getAbsolutePath ();
// turn it into an in-memory object
XmlDocument doc = XmlDocumentBuilder.createXmlDocument(uri);
Element root = doc.getDocumentElement();
.......

Now I want to do the same thing but I have the file at a specific URL.
I have tried
URL url = new URL(argv[0]);
//where for e.g. argv[0] = "http://www.xyz.edu/xyx.xml"

InputStream in = url.openStream();
..
XmlDocument doc = XmlDocumentBuilder.createXmlDocument(in);
...

But it does not work.

Does anybody has a solution for this??

Thanks
SPK


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


From ketil at ii.uib.no  Fri Nov 27 08:50:32 1998
From: ketil at ii.uib.no (Ketil Z Malde)
Date: Mon Jun  7 17:06:45 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: <david@megginson.com>'s message of "Thu, 26 Nov 1998 10:53:38 -0500 (EST)"
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk> <13917.30241.570011.273728@localhost.localdomain>
Message-ID: <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>

<david@megginson.com> writes:

> XML is a metalanguage for defining markup languages: in the markup
> languages that you define with it, you can do any sort of data typing
> you want:

[snip object-oriented XML]

> Your complaint is not that XML does not support data typing, but that
> generic XML parsing tools do not enforce the kind of data typing that
> you need out of the box.  One of the reasons for this is that
> everyone's requirements are different; I might want

>   <name type="city">Kingston</name>

> where the type is enforced to be the name of a city that is currently
> in my database.  Someone else might want

>   <subject type="LC">BS</subject>

> where the contents must be a Library of Congress subject.

I don't know the number of LC subjects, but since this information is
static, I assume you could put it in an attribute where only LC
subjects are legal values.

What could be useful and relatively simple, is a restriction of the
*form* of the data, e.g. forcing the <name type="city"> to contain
only letters and start with a capital, or LC subjects to be two upper
case letters (if that's what they are).  Phone numbers, dates, sort
keys, there are many cases where it would be helpful to have the
parser catch these things, I think.

You could equally well embed this in your tools, and I guess you have
to draw a more or less arbitrary line somewhere between what
information is processing independent, and what is not.

~kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Fri Nov 27 09:16:14 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:45 2004
Subject: Computer Weekly
Message-ID: <000b01be19e5$e97e5b50$7008e391@bra01wmhkay.bra01.icl.co.uk>

Computer Weekly, a popular trade paper in the UK, leads its front page this
week with an article on XML, claiming somewhat incoherently that Microsoft
are pushing it as an alternative to DCOM. If anyone knows what stick they
got the wrong end of, I would be interested to know!

See www.computerweekly.co.uk (registration required).

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Fri Nov 27 12:08:51 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:45 2004
Subject: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
In-Reply-To: <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
	<13917.30241.570011.273728@localhost.localdomain>
	<david@megginson.com>
	<KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
Message-ID: <13918.37357.415536.417680@localhost.localdomain>

Ketil Z Malde writes:

 > What could be useful and relatively simple, is a restriction of the
 > *form* of the data, e.g. forcing the <name type="city"> to contain
 > only letters and start with a capital, or LC subjects to be two upper
 > case letters (if that's what they are).  Phone numbers, dates, sort
 > keys, there are many cases where it would be helpful to have the
 > parser catch these things, I think.

Ketil is writing from Norway, so he has probably already had some
(unpleasant) experiences with L10N issues in software coming from
North America.  Read on...

Imagine that someone sent an expensive XML-based system from North
America to Norway, and you discovered that the system constrained
phone numbers to consist of exactly 10 digits (XXX XXX-XXXX): you
would be quite right to demand a quick fix or a refund.  Now, imagine
that someone sent an XML-based system from Norway to Beijing, and it
constrained city names to contain only Roman letters (accented and
unaccented); in fact, you don't need to go so far -- even the good
people of Long Beach and the nuns of Sainte-Marie-d'en-Haut need
spaces, apostrophes, and dashes as well as Roman characters in their
place names.

I'm not suggesting that a set of simple XML data-typing constraints
cannot be helpful -- if you're building a database only of Norwegian
city names, you know that you don't have to deal with Han or Kanji
(unless, of course, you do such a good job that you decide to
commercialise your system) -- but coming up with data-type constraints
that both useful and generalised enough for all XML users across all
of the major Locales and all of the Unicode character repetoire is
*very* difficult.


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


From ketil at ii.uib.no  Fri Nov 27 13:06:06 1998
From: ketil at ii.uib.no (Ketil Z Malde)
Date: Mon Jun  7 17:06:45 2004
Subject: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
In-Reply-To: <david@megginson.com>'s message of "Fri, 27 Nov 1998 07:07:02 -0500 (EST)"
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk> <13917.30241.570011.273728@localhost.localdomain> <david@megginson.com> <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no> <13918.37357.415536.417680@localhost.localdomain>
Message-ID: <KETIL-86btlt5j4o.fsf@ketilboks.bgo.nera.no>

<david@megginson.com> writes:

> Imagine that someone sent an expensive XML-based system from North
> America to Norway, and you discovered that the system constrained
> phone numbers

> XML-based system from Norway to Beijing, and it constrained city
> names to contain only Roman letters

I see the problem, but that constraint is IMHO an indication that
you somehow has encountered an area the system is unable to deal
with.  And very probably, you need to change other components of your
system as well.  Catching illegal values early on - in validation of
the document - instead of relying on some obscure run-time error in
some program, is a *feature*.

One occasion I've run into, was when I needed sort keys for a list of
records.  Unfortunately, the data quality was not very good, and there 
were a lot of characters without defined sort semantics stuck in the
sort field.  I had, in effect, to write a small tool that parsed the
data, and came up with the illegal keys.

If content constraints were supported in the DTD and validator, I
could have thrown the DTD at my customers and said that this is what
I accept, and they would be free to use whatever tools they chose to
verify that what they send me is valid.

> but coming up with data-type constraints that both useful and
> generalised enough for all XML users across all of the major Locales
> and all of the Unicode character repetoire is *very* difficult.

Only slightly more difficult than coming up with the DTD, IMHO, and
certainly a lot less difficult than ensuring that your processing
environment correctly deals with all ``major Locales'' and Unicode
byzantinery and all.

~kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Fri Nov 27 13:49:23 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:45 2004
Subject: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
In-Reply-To: <KETIL-86btlt5j4o.fsf@ketilboks.bgo.nera.no>
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
	<13917.30241.570011.273728@localhost.localdomain>
	<david@megginson.com>
	<KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
	<13918.37357.415536.417680@localhost.localdomain>
	<KETIL-86btlt5j4o.fsf@ketilboks.bgo.nera.no>
Message-ID: <13918.43698.18691.524793@localhost.localdomain>

Ketil Z Malde writes:

 > Catching illegal values early on - in validation of the document -
 > instead of relying on some obscure run-time error in some program,
 > is a *feature*.

Agreed -- this is a very good choice, especially if you have human
authors.

The real question, though, is how constraints could be enforced.
Let's start with an extremely simple example:

  <value xml:type="float"></value>

What are the allowed contents?  Certainly, +, -, and the digits 0-9
should be allowed, as well as the letter 'e', but which of the
following should throw an error?

  <value xml:type="float">1,5</value>
  <value xml:type="float">1.5</value>

There are three obvious answers:

1. Both are accepted.
2. Only one is accepted, and everyone learns to use that format.
3. Only the correct one for the current locale is accepted.

Option #2 is politically unworkable (either France or the U.S. would
take up arms), and option #1 seriously weakens validation (what if an
English author had mistakenly intended to use the comma to specify a
range?).  Option #3 looks OK on the surface, but it is actually the
worst of the three because it destroys interoperability: same XML
document may be considered correct by some parsers and erroneous by
others, depending on what locale the user happened to choose.

This is a very simple example; after you've worked this out, you can
start worrying about how to count combining characters with
field-length restrictions, etc.


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


From ketil at ii.uib.no  Fri Nov 27 14:21:30 1998
From: ketil at ii.uib.no (Ketil Z Malde)
Date: Mon Jun  7 17:06:45 2004
Subject: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
In-Reply-To: <david@megginson.com>'s message of "Fri, 27 Nov 1998 08:47:59 -0500 (EST)"
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk> <13917.30241.570011.273728@localhost.localdomain> <david@megginson.com> <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no> <13918.37357.415536.417680@localhost.localdomain> <KETIL-86btlt5j4o.fsf@ketilboks.bgo.nera.no> <13918.43698.18691.524793@localhost.localdomain>
Message-ID: <KETIL-867lwh5fnf.fsf@ketilboks.bgo.nera.no>

<david@megginson.com> writes:

> The real question, though, is how constraints could be enforced.
> Let's start with an extremely simple example:

>   <value xml:type="float"></value>

Now you're adding type information to the content, what I suggested
was to constrain *form*.  For one thing, I would not specify this in
the document (this is just a gut feeling, but why would you?), I would
specify it in the DTD, e.g. like so:

	<!element value #REGEXP:"-?[0-9]*.[0-9][0-9]">

(or some such, you get the point).  

> What are the allowed contents?

Then the document could contain

	<value>4.50</value>
	<value>-0.01</value> or
	<value>.00</value>

but not

	<value>1.0</value> or
	<value>4,50</value>

>   <value xml:type="float">1,5</value>
>   <value xml:type="float">1.5</value>

This won't be a problem, if the DTD specifies what can the processing
software should expect.  You could even validate processing software
to some extent. 

> This is a very simple example; after you've worked this out, you can
> start worrying about how to count combining characters with
> field-length restrictions, etc.

I think trying to define some set of types to be used in *all* XML
documents is taking the wrong approach.  I don't really see this as
either workable or desirable.  What would the point of using xml:type
be?  As I said, I haven't given this a lot of thought, but to me, it
seems like having elements which take multiple types that need to be
identified in attributes would be an indication of an ill designed
document type.  (What would, in the example above, the semantics be if 
you supplied an xml:type="string" in a value field?)

Specifying subsets of #PCDATA as allowable content, however, should be
relatively simple and occasionally useful.  But hey, I'm in
telecommunications these days, not document processing :-)

~kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From b.laforge at jxml.com  Fri Nov 27 14:40:30 1998
From: b.laforge at jxml.com (Bill la Forge)
Date: Mon Jun  7 17:06:45 2004
Subject: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
Message-ID: <001801be1a14$4696ab20$ab026982@thing1.camb.opengroup.org>

David,

There may be times when there is good justification for strong
typing. So the programmer puts in the validation logic.

Now, if the requirements change, due to a integration project
or a change in local, then the situation is a whole lot better
if the validation logic is meta-data driven. 

I will not argue that a DTD is a good place to put this. But I will
argue that the programmer needs to be tempted with something
better than interlacing validation and application logic.

I'd also like to argue that where ever you put the data typing,
you also need to support type transforms, i.e. the ability
to specify source type and destination type.  (I've been thinking 
about SAX event filters lately.)

Bill


-----Original Message-----
From: david@megginson.com <david@megginson.com>
To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk>
Date: Friday, November 27, 1998 8:55 AM
Subject: Re: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)


>Ketil Z Malde writes:
>
> > Catching illegal values early on - in validation of the document -
> > instead of relying on some obscure run-time error in some program,
> > is a *feature*.
>
>Agreed -- this is a very good choice, especially if you have human
>authors.
>
>The real question, though, is how constraints could be enforced.
>Let's start with an extremely simple example:
>
>  <value xml:type="float"></value>
>
>What are the allowed contents?  Certainly, +, -, and the digits 0-9
>should be allowed, as well as the letter 'e', but which of the
>following should throw an error?
>
>  <value xml:type="float">1,5</value>
>  <value xml:type="float">1.5</value>
>
>There are three obvious answers:
>
>1. Both are accepted.
>2. Only one is accepted, and everyone learns to use that format.
>3. Only the correct one for the current locale is accepted.
>
>Option #2 is politically unworkable (either France or the U.S. would
>take up arms), and option #1 seriously weakens validation (what if an
>English author had mistakenly intended to use the comma to specify a
>range?).  Option #3 looks OK on the surface, but it is actually the
>worst of the three because it destroys interoperability: same XML
>document may be considered correct by some parsers and erroneous by
>others, depending on what locale the user happened to choose.
>
>This is a very simple example; after you've worked this out, you can
>start worrying about how to count combining characters with
>field-length restrictions, etc.
>
>
>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/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jborden at mediaone.net  Fri Nov 27 14:42:51 1998
From: jborden at mediaone.net (Borden, Jonathan)
Date: Mon Jun  7 17:06:46 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <000c01be1a13$e54d6cf0$d3228018@jabr.ne.mediaone.net>

As far as I can tell, the only documents I know of which is truly organized
for human communication have MIME types of "text/plain". Even this makes the
basic assumption that a computer or terminal is available to display the
bits as ASCII text. In general, digital documents *all* require some
transformation in order to interface to the human either via its optical
input, the retina, audio input, the cochlea or tactile input. Hence we might
argue that "image/jpeg" and "audio/wave" (or whatever a sound clip is!) are
equally organized for human communication. PDF is no better than HTML or
SMIL or whatever other type of XML or SGML document type in being organized
for human communication as all require transformation for screen display
(which is the human communication interface). Certainly the average human
cannot read a raw HTML document nor can they read a raw PDF document.

Under the SGML/XML definition, everything is either a document or part of a
document so it is just a matter of opinion as to whether XML is 'optimized'
for 'documents' or 'data'. To me, XML itself is optimized for neither/both,
rather certain applications/DTD's/transforms are optimized for one or the
other.

Jonathan Borden
JABR Technology Corp.
http://jabr.ne.mediaone.net


>Michael Kay wrote:
>
> A document is information organised for human communication; data is
> information organised for machine processing. XML can do both, but I stick
> with my original claim that it is optimised for the former.
>


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From paul at prescod.net  Fri Nov 27 15:43:34 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:46 2004
Subject: Internal subset equivalent in new schema proposals?
References: <009701be1972$5a2f0670$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <365EC599.1A9735B8@prescod.net>

Michael Kay wrote:
> 
> While Paul Prescod asserts:
> >SGML and XML are explicitly about organizing information for machine
> >processing. So according to your definition, SGML is about data, not
> >documents.
> 
> Well, I know that SGML folks have always seen SGML as the solution to
> everything, 

Your presence here is evidence that we were correct.

> but I don't think they've erased the evidence of where it came
> from, which was device-independent typographical markup.

SGML was always about non-typographical markup. It was always about
treating documents *as data*.

> If you were to design something for processing data (not just rendering it),

Rendering data *is* processing it. There is no distinction there.

> you'd have support for the kind of data models recognised in the database
> world; you'd have integrity constraints (including data types and primary
> keys); 

But SGML is not a data modelling language -- it is a language description
language. The world has many data modelling languages -- some of them very
good. It has only one language description language at XML's level. It is
highly debatable whether it makes sense to have a single schema for both
the language (the serialization) and the data model.

In fact, I'll go so far as to say that it does NOT make sense. SGML goes
*too far* in this direction: the ID/IDREF mechanism should be treated at a
separate level, like other integrity constraints.

> you'd have declarative query languages and report writers rather than
> navigational APIs and style sheets; 

Neither SGML nor XML say anything about navigational APIs or stylesheets.

> you'd have relationships rather than hyperlinks; 

"A hyperlink is a typed relationship among two or more objects, each of
which fulfills a unique role in the relationship."

"The term "hyperlink" is used in preference to the unqualified term "link"
to avoid confusion with the SGML processing link feature. However, the
term "link" can be used with more restrictive qualifying adjectives, as in
"hypertext link", or with no qualifiers when the context is clear."

http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-8.1.html

> and (to be trivial about it) you'd have examples in the domain
> of customers and orders, not books and poems.

Where? We have examples from both domains in the book I co-wrote. I focus
on document structures, however, because they form a superset of
relational data structures. I could show a database of "dates" but I can
get double mileage by putting the date in a letter or memo. Also, the
first rule of example writing is to try and do something concrete.
Databases are abstract to most people. Documents are concrete.

> It so happens that XML is better for doing application-to-application data
> interchange than things (like ASN.1) that were supposedly designed for the
> job, so I don't begrudge it. 

It doesn't "so happen." Charles Goldfarb set out to solve a bigger, harder
problem and (not surprisingly) came up with a more general, flexible
solution.

> But XML (including its friends and relations)
> is full of things that wouldn't be there if that were its original primary
> purpose, and I really don't see how one can claim otherwise.

There is no doubt that this is the case. I've tried to be explicit that
SGML and XML solve a superset of the relational/object database
interchange problem. If it had been designed for database serialization,
it wouldn't have a concept of "mixed content" (for example). My only point
in this discussion is that specific flaws that you have described cannot
be traced to a document-orientedness. They are just flaws. 

Nobody has yet shown me a sort of data that does not appear in documents
and does not need complex processing in that context.

This is an important issue because it informs how we should go forward. In
my experience, any solution which solves the document world's
serialization problems will trivially solve the database world's
serialization problems. (Once again) That's why we are having this
discussion today. But some of the schema proposals (like DCD) involve
solutions to problems that DO NOT SCALE to complex problems. They will
solve the database world's problems for a time, but they do not solve the
whole problem.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From murray at muzmo.com  Fri Nov 27 18:25:25 1998
From: murray at muzmo.com (Murray Maloney)
Date: Mon Jun  7 17:06:46 2004
Subject: Why XML data typing is hard (was Re: Internal subset
  equivalent in new schema proposals?)
In-Reply-To: <13918.37357.415536.417680@localhost.localdomain>
References: <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
 <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
 <13917.30241.570011.273728@localhost.localdomain>
 <david@megginson.com>
 <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
Message-ID: <3.0.1.32.19981127131312.006d85a4@pop.uunet.ca>

At 07:07 AM 11/27/98 -0500, david@megginson.com wrote:
>I'm not suggesting that a set of simple XML data-typing constraints
>cannot be helpful -- if you're building a database only of Norwegian
>city names, you know that you don't have to deal with Han or Kanji
>(unless, of course, you do such a good job that you decide to
>commercialise your system) -- but coming up with data-type constraints
>that both useful and generalised enough for all XML users across all
>of the major Locales and all of the Unicode character repetoire is
>*very* difficult.

David, I am surprised by this comment.

Essentially you are saying that since
it would be possible to design poorly
with a given set of tools, we should not
provide these design tools.

Doing the hard stuff is what might give 
one product a competitive advantage over
another. Doing it poorly is what should 
cause the market to reject a product.



Murray Maloney, Esq.          Phone: (905) 509-9120
Muzmo Communication Inc.      Fax:   (905) 509-8637
671 Cowan Circle              Email: murray@muzmo.com
Pickering, Ontario 		Email: murray@yuri.org
Canada, L1W 3K6    		

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Fri Nov 27 19:25:13 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:46 2004
Subject: Why XML data typing is hard (was Re: Internal subset
  equivalent in new schema proposals?)
In-Reply-To: <3.0.1.32.19981127131312.006d85a4@pop.uunet.ca>
References: <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
	<007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
	<13917.30241.570011.273728@localhost.localdomain>
	<david@megginson.com>
	<13918.37357.415536.417680@localhost.localdomain>
	<3.0.1.32.19981127131312.006d85a4@pop.uunet.ca>
Message-ID: <13918.63671.166783.57835@localhost.localdomain>

Murray Maloney writes:

 > Essentially you are saying that since it would be possible to
 > design poorly with a given set of tools, we should not provide
 > these design tools.

No, I think that Murray has misunderstood -- I'm trying to manage
expectations by explaining that the XML data-typing problem is far
more difficult than a typical anglophone North American SQL specialist
might expect, and that the potential rewards are smaller than people
might hope.

I will happily use data-typing once it's approved, but I don't imagine
that it will generate more than a tiny, incremental gain in my
productivity or in the integrity of my information (with database
programming, you always end up writing the hard validations by hand
anyway).

And, of course, any data-typing standard blessed by the XML-Syntax WG
will have to be fully Internationalised -- a standard that works only
for English-speaking Perl hackers in the Silicon Valley needs to be
designed by Perl hackers in the Silicon Valley, not by the W3C.


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


From murray at muzmo.com  Fri Nov 27 21:16:37 1998
From: murray at muzmo.com (Murray Maloney)
Date: Mon Jun  7 17:06:46 2004
Subject: Why XML data typing is hard (was Re: Internal subset 
  equivalent in new schema proposals?)
In-Reply-To: <13918.63671.166783.57835@localhost.localdomain>
References: <3.0.1.32.19981127131312.006d85a4@pop.uunet.ca>
 <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
 <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
 <13917.30241.570011.273728@localhost.localdomain>
 <david@megginson.com>
 <13918.37357.415536.417680@localhost.localdomain>
 <3.0.1.32.19981127131312.006d85a4@pop.uunet.ca>
Message-ID: <3.0.1.32.19981127161644.006db1d0@pop.uunet.ca>

At 02:23 PM 11/27/98 -0500, david@megginson.com wrote:
>Murray Maloney writes:
>
> > Essentially you are saying that since it would be possible to
> > design poorly with a given set of tools, we should not provide
> > these design tools.
>
>No, I think that Murray has misunderstood -- I'm trying to manage
>expectations by explaining that the XML data-typing problem is far
>more difficult than a typical anglophone North American SQL specialist
>might expect, and that the potential rewards are smaller than people
>might hope.

I don't think that I misunderstood at all.

I agree that XML data-typing could be a very difficult problem.
Especially if we insist on making it so. But I think that 
rewards are potentially much greater than you are allowing.
And I think that we can take small steps toward data nirvanna
-- I think that the greatest danger lies in the belief that
the importance of an ideal or complete solution should hold up
the next reasonable step.
>
>I will happily use data-typing once it's approved, but I don't imagine
>that it will generate more than a tiny, incremental gain in my
>productivity or in the integrity of my information (with database
>programming, you always end up writing the hard validations by hand
>anyway).

Well, reasonable people can disagree, but I wonder why in this case.
>
>And, of course, any data-typing standard blessed by the XML-Syntax WG
>will have to be fully Internationalised -- a standard that works only
>for English-speaking Perl hackers in the Silicon Valley needs to be
>designed by Perl hackers in the Silicon Valley, not by the W3C.

Well, I qualify only inasmuch as English is one of the languages 
which I read/write/speak. So, that dart seems to have missed 
me as a target -- 404. I am not interested in a datatyping solution
that is only usable by db or Perl hackers. See SOX.





Murray Maloney, Esq.          Phone: (905) 509-9120
Muzmo Communication Inc.      Fax:   (905) 509-8637
671 Cowan Circle              Email: murray@muzmo.com
Pickering, Ontario 		Email: murray@yuri.org
Canada, L1W 3K6    		

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Sat Nov 28 05:25:38 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:46 2004
Subject: Internal subset equivalent in new schema proposals?
In-Reply-To: <365EC599.1A9735B8@prescod.net> from "Paul Prescod" at Nov 27, 98 09:30:33 am
Message-ID: <199811280553.AAA05471@locke.ccil.org>

Paul Prescod scripsit:

> In fact, I'll go so far as to say that it does NOT make sense. SGML goes
> *too far* in this direction: the ID/IDREF mechanism should be treated at a
> separate level, like other integrity constraints.

IMHO the purpose of ID/IDREF is to express non-hierarchical data using
hierarchical notation.  Appropriate use of ID and IDREF attributes
allows the representation of any directed graph, whether acyclic or
cyclic.

-- 
John Cowan					cowan@ccil.org
		e'osai ko sarji la lojban.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From gkholman at CanadaMail.com  Sat Nov 28 11:39:32 1998
From: gkholman at CanadaMail.com (G. Ken Holman)
Date: Mon Jun  7 17:06:46 2004
Subject: Why XML data typing is hard (was Re: Internal subset
  equivalent in new schema proposals?)
In-Reply-To: <KETIL-867lwh5fnf.fsf@ketilboks.bgo.nera.no>
References: <david@megginson.com>
 <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
 <13917.30241.570011.273728@localhost.localdomain>
 <david@megginson.com>
 <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no>
 <13918.37357.415536.417680@localhost.localdomain>
 <KETIL-86btlt5j4o.fsf@ketilboks.bgo.nera.no>
 <13918.43698.18691.524793@localhost.localdomain>
Message-ID: <Version.32.19981128020813.0111b640@CraneSoftwrights.com>

At 98/11/27 16:17 +0100, Ketil Z Malde wrote:
><david@megginson.com> writes:
>
>> The real question, though, is how constraints could be enforced.
>> Let's start with an extremely simple example:
>
>>   <value xml:type="float"></value>
>
>Now you're adding type information to the content, what I suggested
>was to constrain *form*.  For one thing, I would not specify this in
>the document (this is just a gut feeling, but why would you?), I would
>specify it in the DTD, e.g. like so:
>
>	<!element value #REGEXP:"-?[0-9]*.[0-9][0-9]">
>
>(or some such, you get the point).  
>
>> What are the allowed contents?
>
>Then the document could contain
>
>	<value>4.50</value>
>	<value>-0.01</value> or
>	<value>.00</value>
>
>but not
>
>	<value>1.0</value> or
>	<value>4,50</value>

Then your example proposed range of values is inappropriate because "4,50"
is a valid float from an I18N point of view.

In Canada, valid expressions of currency numbers are $1.47 or 1,47$ based
on where you are.  The decimal separator is "." in English Canada and ","
in French Canada.

I understood David's point to be that two valid expressions of the same
float aren't lexically the same.

>>   <value xml:type="float">1,5</value>
>>   <value xml:type="float">1.5</value>
>
>This won't be a problem, if the DTD specifies what can the processing
>software should expect.  You could even validate processing software
>to some extent. 

And I suppose your regular expression example could be changed to 

	<!element value #REGEXP:"-?[0-9]*(\.|,)[0-9][0-9]">

Currency values would need a larger expression.

I gather from Michael S-McQ in a presentation in Chicago that the regular
expression for a valid date (taking into account days of the month and leap
years) is 4801 characters long.

Since these values themselves are hierarchical, one could model the example
as:

  <whole>4</whole><part>50</part>

but one couldn't do that with the separate elements

  <year>1998</year><month>02</month><day>29</day>

and know it was invalid without the concept of the set representing a valid
date.

>I think trying to define some set of types to be used in *all* XML
>documents is taking the wrong approach.  I don't really see this as
>either workable or desirable.  What would the point of using xml:type
>be?  

Perhaps to abstract what is being expressed in markup to allow different
lexical expressions of the same value to be considered valid.

............ Ken



--
G. Ken Holman         mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/x/
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
Training:   http://www.CraneSoftwrights.com/x/schedule.htm
Resources: http://www.CraneSoftwrights.com/x/resources.htm
Shareware: http://www.CraneSoftwrights.com/x/shareware.htm


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 28 15:38:56 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:46 2004
Subject: Internal subset equivalent in new schema proposals?
References: <199811280553.AAA05471@locke.ccil.org>
Message-ID: <366015BA.AFB7C044@prescod.net>

John Cowan wrote:
> 
> Paul Prescod scripsit:
> 
> > In fact, I'll go so far as to say that it does NOT make sense. SGML goes
> > *too far* in this direction: the ID/IDREF mechanism should be treated at a
> > separate level, like other integrity constraints.
> 
> IMHO the purpose of ID/IDREF is to express non-hierarchical data using
> hierarchical notation.  Appropriate use of ID and IDREF attributes
> allows the representation of any directed graph, whether acyclic or
> cyclic.

That's fine, but it isn't clear why XML must be able to support directed
graphs at its most basic level. We know that we need multiple levels to
support multiple types of structures.

We also know that one of the requirements for supporting directed graphs
*properly* is the ability to do relative addressing (that's why we have
XPointer). But ID/IDREF can't do that. ID/IDREF also has a very inflexible
namespace mechanism. Strictly speaking it is "enough" in that every
element is addressable, but practically speaking it does not allow us to
express the structure explicitly enough.

<EMPLOYEE NAME="John_Smith" POSITION_ID="CEO" LOCATION_ID="ROOM_115">

This element has three unique identifiers, each unique in a different
namespace.

In other words, ID/IDREF strikes me as the kind of half-solution likely to
be thought up by someone corrupted by too much exposure to SQL and not
enough to documents. :) :) :)

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco
Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cbullard at hiwaay.net  Sat Nov 28 16:55:36 1998
From: cbullard at hiwaay.net (len bullard)
Date: Mon Jun  7 17:06:46 2004
Subject: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
References: <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk>
		<13917.30241.570011.273728@localhost.localdomain>
		<david@megginson.com>
		<KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no> <13918.37357.415536.417680@localhost.localdomain>
Message-ID: <36602A7F.38A1@hiwaay.net>

david@megginson.com wrote:
> 
> I'm not suggesting that a set of simple XML data-typing constraints
> cannot be helpful -- if you're building a database only of Norwegian
> city names, you know that you don't have to deal with Han or Kanji
> (unless, of course, you do such a good job that you decide to
> commercialise your system) -- but coming up with data-type constraints
> that both useful and generalised enough for all XML users across all
> of the major Locales and all of the Unicode character repetoire is
> *very* difficult.

Yes.  I think you have presented good arguments why a declaration for 
conventional/primitive datatypes should not be in XML 1.0.  However, 
such a declaration has been asked for and is useful.  For example, 
languages such as VRML have to declare such types to ensure the 
efficiency of the application language.  Applications such as 
relational databases have to declare datatypes to insure integrity.  
A common reference for these will be of value to the application 
language communities that require them and intend to use SGML/XML 
for their schema.  Given that XML is a product of the W3C, it is 
the responsibility of the W3C to produce a product to support this 
requirement.  A separate reference would be ideal.

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


From db at Eng.Sun.COM  Sat Nov 28 16:58:33 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:46 2004
Subject: "Chinese XML Now!" Project
References: <009b01be17a7$36f166c0$2cf96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <36602A11.4F01C6F3@eng.sun.com>

Rick,

> Initially we will target the Big5 encoding only. (Other groups may
> contribute other Chinese encodings.)

For the record, we've had several reports of successful use of
Sun's XML package with the Big5 encoding.  Just using the JDK's
built-in support seems to work nicely for Java based systems.
(I think that information should help address both your goals!)

For the edification of those of us who aren't fluent in Chinese,
could you perhaps summarize what Big5 does?  Is it superset of
ASCII that supports traditional Chinese glyphs?  How does Big5
differ from other encodings that support similar glyphs?  Who
uses Big5?

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 28 17:16:43 1998
From: rja at arpsolutions.demon.co.uk (Richard Anderson)
Date: Mon Jun  7 17:06:46 2004
Subject: File Search with XML output - XFind
Message-ID: <000601be1af2$ef3ca750$c5010180@p197>

Hi,

Having nothing better to do today, I've spent a few hours writing a little
freeware file search application that given a filename wildcard, recursivly
searches directories and generates an XML file that contains the search
results.   ( The app only runs under windows )

Using IE5 & it's XML/CSS formatting, the output can then be viewed in a
'sort of' pretty fashion.  (The long term goal is to use the output from
XFind to feed another application called XSync )

If your interested in this fun little project.  The URL is:

http://www.arpsolutions.demon.co.uk/xml/xfind/index.htm

Other XML tools and info can be found at :

http://www.arpsolutions.demon.co.uk/xml/index.htm

I'll probably expand the app as I use it, but suggestions for features etc
are very welcome.

Regards,

Richard.

***********************************************
* E-Mail  mailto:RJA@arpsolutions.demon.co.uk *
* WEB     http://www.arpsolutions.demon.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Sat Nov 28 17:28:39 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:46 2004
Subject: Sun XML Lib
References: <19981127073159.21022.qmail@hotmail.com>
Message-ID: <3660316B.8B994AF2@eng.sun.com>

"Prashanth K. Salur" wrote:
> 
> I have tried
> URL url = new URL(argv[0]);
> //where for e.g. argv[0] = "http://www.xyz.edu/xyx.xml"
> 
> InputStream in = url.openStream();
> ..
> XmlDocument doc = XmlDocumentBuilder.createXmlDocument(in);
> ...
> 
> But it does not work.
> 
> Does anybody has a solution for this??

Not without seeing the diagnostics you were given !!

My _guess_ would be that the "xyz.xml" file includes some
sort of relative URL in it (e.g. for the DTD).  To fix that
class of problem, just feed argv[0] directly into the
document builder so that the parser can resolve it, or else
modify the document so it doesn't use a relative URL.  This
particular issue is noted in the method's documentation,
but it nonetheless seems to get a bit of confusion.

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


From db at Eng.Sun.COM  Sat Nov 28 17:43:22 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:46 2004
Subject: relation between DOM, SAX, and Schema?
References: <0e9601be18ce$df80c380$0200a8c0@mdaxke.mediacity.com>
Message-ID: <366034B6.B0C1FE6B@eng.sun.com>

"Mark D. Anderson" wrote:
> 
> 1. Is the difference between DOM and SAX one of programming
> style only (implementation efficiency aside)?

In addition to David Megginson's points, I'll point out that
DOM supports providing more information than SAX exposes.  

There are reasonable arguments to be had about how useful that
additional information is, really -- comments aren't supposed
to hold information used by a program, as one example, though
it's reasonable to let programs emit commented XML.  (Not that
DOM level 1 lets you emit XML! :-)

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Sat Nov 28 18:28:07 1998
From: begeddov at jfinity.com (Gabe Beged-Dov)
Date: Mon Jun  7 17:06:46 2004
Subject: SAX and delayed entity loading
Message-ID: <001901be1afc$f42a0d70$160016c0@jfinity1>

I have been performing thought experiments (in other words, I haven't
actually tried it out :-) on how to delay loading of external entities using
SAX. The scenario is you want to do browser style incremental presentation
where you delegate any external entity loading to separate SAX pipelines.
You want to spew the overrall structure into the users' face as quickly as
possible and then fill in the blanks.

My impression of the SAX architecture is that the parser is expecting to
handle all loading of external entities itself. It will call the
EntityResolver expecting to get either a system identifier or a stream.
There doesn't seem to be a third possibility of "ignore this entity".

It seems you can fake this by  returning a dummy stream to the parser from
your resolver. This dummy stream would have minimal well formed content
(could it be empty?) and then on you go. Are there other possibilities?

Gabe Beged-Dov
www.jfinity.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ricko at allette.com.au  Sun Nov 29 06:47:22 1998
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun  7 17:06:46 2004
Subject: "Chinese XML Now!" Project
Message-ID: <001701be1b64$797f0680$62f96d8c@NT.JELLIFFE.COM.AU>


From: David Brownell <db@Eng.Sun.COM>

> Is (Big5) superset of ASCII that supports traditional Chinese glyphs?

Yes. (However, there is a very large view that the difference is really a
character difference, not a glyph difference. Not a fruitful debate for us
here.)

>How does Big5 differ from other encodings that support similar glyphs?

Large: 13500 characters. Not national standard. Nasty encoding: octets
with value < 128 are used as second byte, so cannot be used with generic
8-bit software (eg for pattern matching) without some intervention.

>Who uses Big5?

ROC (Taiwan) and SAR (Hong Kong). I see SAR is starting to use a superset
of Big5 now, with some extra characters from PRC (China). I dont know what
they are, but I suspect they are simplified characters.


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


From rob at robco-inc.com  Sun Nov 29 16:51:31 1998
From: rob at robco-inc.com (Rob Williams)
Date: Mon Jun  7 17:06:47 2004
Subject: Sun's XML Classes
Message-ID: <773251A595CFD111B8F800A0C998C55102CF93@ris3.robco-inc.com>

I downloaded the Early Access of the Sun classes and they work ok, so far
for what I've wanted to do with them. My question is, has anyone else found
that you end up writing a lot of ugly code to get simple things done? Maybe
I'm missing something? Here's an excerpt:

        billTo.appendChild(btCoName);
        billTo.appendChild(new TextNode("\n"));
        btCoName.appendChild(doc.createTextNode(btCoNameFld.toString()));
        billTo.appendChild(btAdd1);
        billTo.appendChild(new TextNode("\n"));
        btAdd1.appendChild(doc.createTextNode(btAdd1Fld.toString()));
        billTo.appendChild(btAdd2);
        billTo.appendChild(new TextNode("\n"));
        btAdd2.appendChild(doc.createTextNode(btAdd2Fld.toString()));
        billTo.appendChild(btCity);
        billTo.appendChild(new TextNode("\n"));
        btCity.appendChild(doc.createTextNode(btCityFld.toString()));
        billTo.appendChild(btState);
        billTo.appendChild(new TextNode("\n"));
        btState.appendChild(doc.createTextNode(btStateFld.toString()));
        billTo.appendChild(btZip);
        billTo.appendChild(new TextNode("\n"));
        btZip.appendChild(doc.createTextNode(btZipFld.toString()));
        billTo.appendChild(new TextNode("\n"));

Rob Williams
RobCo Incorporated


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From fitzhugh at cup.hp.com  Sun Nov 29 18:29:33 1998
From: fitzhugh at cup.hp.com (Andrew Fitzhugh)
Date: Mon Jun  7 17:06:47 2004
Subject: Computer Weekly
Message-ID: <004f01be1bc5$e5c47f80$a2b24b0f@ce174426.cup.hp.com>

I did not read the article (I'm not willing to register and supply them all
personal contact information they required), but they may have it right.  I do
know that Microsoft had a press release earlier this year on SOAP (Simple Object
Access Protocol).  SOAP is an XML-based way to do RPC-like things, and could be
an alternative protocol to be used to extend DCOM to the Internet.  MS has said
nothing about SOAP since the initial press release, perhaps they are talking
now.

-- Andy
________________________________________________________________________
Andrew Fitzhugh                                      fitzhugh@cup.hp.com
HP Internet Imaging Operation                   http://hplaef.cup.hp.com

-----Original Message-----
From: Michael Kay <M.H.Kay@eng.icl.co.uk>


Computer Weekly, a popular trade paper in the UK, leads its front page this
week with an article on XML, claiming somewhat incoherently that Microsoft
are pushing it as an alternative to DCOM. If anyone knows what stick they
got the wrong end of, I would be interested to know!

See www.computerweekly.co.uk (registration required).

Mike Kay



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Sun Nov 29 18:49:29 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:47 2004
Subject: XLinkFilter progress
Message-ID: <199811291849.NAA06338@hesketh.net>

Just an update on the growth and further development of XLinkFilter, a Java
SAX parser filter that can be inserted between a parser and documents to
extract a complete list of links from a document.  XLinkFilter is currently
based on the 3/3/98 draft of XLink, and will be kept up to date with future
developments in the spec.

XLinkFilter creates a LinkSet object that contains unidirectional links
(representing the results of all the links in the document or documents) an
application may use to implement XLink functionality.  All of the
information provided by the XLink spec is included in the LinkSet,
including attributes and connectors.  LinkSets may be combined over the
course of an application, making it easy to make link data last across
multiple documents.

XLinkFilter now (properly) supports connectors (#, |, ?XML-PTR=) in XLink,
and (optionally) can be used with HTML documents.  Multidirectional links
work (as they did in previous versions), and are resolved to sets of
unidirectional links to make it easier for applications to establish
endpoints to implement links.  Future work will focus on support for
extended hub groups, and better support for locations for inline links.

More details are available at
http://www.simonstl.com/projects/xlinkfilter/.  Contributions are welcome;
if anyone uses it in an application, please let me know.  I'll be setting
up an announcement list shortly.


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (November)
Building XML Applications (December)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From ketil at ii.uib.no  Mon Nov 30 08:03:12 1998
From: ketil at ii.uib.no (Ketil Z Malde)
Date: Mon Jun  7 17:06:47 2004
Subject: Why XML data typing is hard (was Re: Internal subset   equivalent in new schema proposals?)
In-Reply-To: "G. Ken Holman"'s message of "Sat, 28 Nov 1998 00:29:01 -0500"
References: <david@megginson.com> <007a01be1946$e02c3030$7008e391@bra01wmhkay.bra01.icl.co.uk> <13917.30241.570011.273728@localhost.localdomain> <david@megginson.com> <KETIL-86g1b5v56e.fsf@ketilboks.networks.nera.no> <13918.37357.415536.417680@localhost.localdomain> <KETIL-86btlt5j4o.fsf@ketilboks.bgo.nera.no> <13918.43698.18691.524793@localhost.localdomain> <Version.32.19981128020813.0111b640@CraneSoftwrights.com>
Message-ID: <KETIL-86lnkt4l0p.fsf@ketilboks.bgo.nera.no>

"G. Ken Holman" <gkholman@canadamail.com> writes:

>> but not
>>	<value>4,50</value>

> Then your example proposed range of values is inappropriate because "4,50"
> is a valid float from an I18N point of view.

I want to specify, in my DTD, what kind of data my processing system
know how to deal with.  Apparently, in my example, the processing
system does not know how to deal with commas in "value"s.  This may or 
may not be an inadequacy with respect to I18N.

Who said anything about "float"?

> In Canada

Yes, yes.  Here too we use commas as decimal ..uh.. points.

> And I suppose your regular expression example could be changed to 

> 	<!element value #REGEXP:"-?[0-9]*(\.|,)[0-9][0-9]">

(whoops, forgot to escape the dot, didn't I)

> I gather from Michael S-McQ in a presentation in Chicago that the regular
> expression for a valid date (taking into account days of the month and leap
> years) is 4801 characters long.

Yes.  Some may want to build all of this into a type system that XML
parsers need to handle, I suppose with mappings to the various
programming languages and machine architectures that may or may not
support that type natively.  As an alternative, I suggested
restricting the *form* instead of the *type* of the content, since 

	a) it's a *lot* simpler to implement, almost trivial
	b) gives the application a clear indication of what data it
	needs to understand
	c) catches errors in data early, avoiding potential run-time
	errors (Y2K?)
	d) avoids a lot of complexity that you probably don't need in
	90% of the cases

Look at the date example.  First you need to embed your 4801 character 
regular expression into parsers that understand xml:type="date".
Then you need the parser to provide something useful, a "struct date", 
a time_t or perhaps a reasonable s-expression, or perhaps some machine 
specific stuff on your embedded system.  And *then* you worry about
what to do when people type "01/02/03". 

Alternatively, you could force people to use "YYYY-MM-DD" by forcing
conformance to a regular expression, and have your applications only
have to deal with that.

And, I think it's pretty obvious that there are a lot of very complex
data types out there.  What's the format for version numbers, for
instance?  Or license plates?  Are you ready to come up with
an xml:type that covers all cases?

(And I bet the 4801-definition doesn't even cover Chinese or Mayan
calendars, or deal correctly with Muslim dates, or seamlessly
integrate Julian and Gregorian.)

>> What would the point of using xml:type be?  

> Perhaps to abstract what is being expressed in markup to allow different
> lexical expressions of the same value to be considered valid.

My point is that you cannot do that without also providing a correct
translation from the lexical expressions of that data type into a
native representation of that data type.  And that translation may not 
make a lot of sense, there are architectures and languages without
concepts such as "float", for instance.

Having all documents be universally understandable and unambigous is a
laudable goal, of course.  But I don't see it happening.

Sorry to be so negative, but at least I didn't mention how I think XML 
is going to destroy the WWW.  Whoops. :-)

~kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From Philippe.Le_Hegaret at sophia.inria.fr  Mon Nov 30 08:30:25 1998
From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret)
Date: Mon Jun  7 17:06:47 2004
Subject: ANN: KOML 1.2 released
Message-ID: <3662578F.ED20550D@sophia.inria.fr>

KOML is an XML application to serialize Java Objects
in an XML document. This application is called KOML
for Koala Object Markup Language.

This new version includes bug fix and a minor change in 
the language (base64 encoding format of the row element).
 (see also http://www.inria.fr/koala/XML/serialization/CHANGES)

 http://www.inria.fr/koala/XML/serialization/

Regards,
Philippe.
---------
Philippe Le Hegaret
Philippe.Le_Hegaret@sophia.inria.fr -- http://www.inria.fr/koala/plh/
KOALA/DYADE/BULL @ INRIA - Sophia Antipolis

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From milla.makelainen.millam at nortel.co.uk  Mon Nov 30 11:59:53 1998
From: milla.makelainen.millam at nortel.co.uk (Makelainen, Milla [HAL02:HK00:EXCH])
Date: Mon Jun  7 17:06:47 2004
Subject: Embedded vCard
Message-ID: <391D82D86F58D111B8250000F805C4D001442CE3@bhari886.europe.nortel.com>

Hi all,

My problem is the following and I hope somebody here can help me out:

I have a XML document as an answer to a query that looks roughly like this

<? xml version="1.0" ?>
<!DOCTYPE answer SYSTEM "answer.dtd">
<answer>
	<caller>Milla</caller>
	<receiver>Henry</receiver>
	<location>office</location>
</answer>

Now, I want to embed vCard DTD
(http://www.ietf.org/internet-drafts/draft-dawson-vcard-xml-dtd-02.txt) into
the document so that inside <caller> and <receiver> I would have vCard
element (something) like this:

	<caller>
		<vCard version ="3.0">
		<fn>Milla</fn>
		</vCard>
	</caller>

So, one answer I guess would be using namespaces? Could I use namespaces in
the following fashion:

<? xml version="1.0" ?>
<answer xmlns="answer.dtd" xmlns:vcrd="vCard.dtd">
	<caller>
		<vcrd:vCard version="3.0">
		<vcrd:fn>Milla</vcrd:fn>
		</vcrd:vCard>
	</caller>
</answer>

However, Frank Dawson recommends in vCard DTD using the following:

<?xml version="1.0" ?>
<!DOCTYPE answer SYSTEM "answer.dtd" 
[
<!NOTATION vCard SYSTEM "vCard.dtd">
<!ENTITY cllr SYSTEM "Milla.vcf" NDATA vCard>
<!ENTITY rcvr SYSTEM "Henry.vcf" NDATA vCard>
]>

<answer>
	<caller vcard="cllr"></caller>
	<receiver vcard="rcvr"></receiver>
	<location>office</location>
</answer>

So problem isn't maybe about how to do the embedding, but more like is there
a standardised way of doing this. Also, do you have any idea of how
validating parsers around would deal with embedding? I have been burning my
brain with this - in vain so far - so I really appreciate any ideas you
have!

Milla

Milla Makelainen
Smart Network Technology, Nortel Networks
email: millam@nortelnetworks.co.uk
tel. +44 (0) 1279 403270
mobile +44 (0) 780 149 5538


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From simonstl at simonstl.com  Mon Nov 30 13:42:34 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:47 2004
Subject: Coins 4 Spec now available
Message-ID: <199811301341.IAA24032@hesketh.net>

The specification for Coins, version 4, is now available.  Coins, for those
who haven't heard of it previously, is a tool for binding XML document
information to Java objects.  XML can be used effectively to serialize Java
objects (in an open format) and programmers can develop Java objects that
operate on particular XML vocabularies.

Coins is now open-source, and the development process for version 4 will be
open as well.  Participation, comments, questions, and suggestions are all
welcome.

See http://www.jxml.com/coins4/index.html for more detailed information on
the specification, licensing, and participation.


Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer
Cookies / Sharing Bandwidth (December)
Building XML Applications (January)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov 30 14:11:04 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:47 2004
Subject: Why XML data typing is hard 
Message-ID: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>

>Then your example proposed range of values is inappropriate because "4,50"
>is a valid float from an I18N point of view.


"4,50" is a localized rendition of a float value. But in XML we should
encourage a rendition-independent encoding of information. (One reason for
having data types is that the default rendition can be determined from the
data type and the locale.) The encoding we choose for floats does not need
to be constrained by human conventions. Any of the notations used in
languages such as C, Java, and SQL would do nicely: and fortunately they are
all very similar.

In fact, I don't think defining data types in XML is harder than in any
other language. In many ways it's easier, because we don't have to worry
about defining operations, only valid states (and perhaps equivalence
rules).

In principle I'm quite happy with data types being defined as an optional
module above XML. My only concerns would be (a) that the XML family of
standards is developing a rather large collection of optional modules which
don't always work well together (as witness Namespaces and XSL), and (b)
that a bolted-on standard might be constrained not to extend the current DTD
syntax.

Mike Kay


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Mon Nov 30 14:45:21 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:47 2004
Subject: Why XML data typing is hard 
In-Reply-To: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <13922.44021.68599.496798@localhost.localdomain>

Michael Kay writes:

 > "4,50" is a localized rendition of a float value. But in XML we
 > should encourage a rendition-independent encoding of information.

That is one of the biggest problems with applying concepts from data
storage to syntax.  XML *is* pure external representation -- in a
database, I can take any of the following appropriate to my locale and
store it internally as the same bunch of bits:

  4,5
  4,50
  4.5
  4.50
  004.500

When I want to render that bunch of bits, I can pick any appropriate
rendition based on the user's locale and formatting requests (for
example, the user might have typed "4.50" into a field in a form, but
the report for a French user might show "04,5").

With XML, though, it is the representation itself that I'm exchanging,
not the abstract data (though perhaps in the future people might want
to pass around compiled DOM trees -- who knows?).  That means that if
I put

  <balance>4.50</balance>

and send the document to a French user, the French user will still see 
the strange, foreign

  <balance>4.50</balance>

There's not a general-purpose, locale-independent way of storing it.
You could define a local-independent text representation of a
floating-point number, but then you're just adding yet another
representation to the list.

Please note that I'm *not* opposed to data typing: I think that it's
necessary and that we will see something like it sooner or later.  I
know that the XML Schema WG plans to work hard on data typing and that
since there are many good, talented people in that WG, they are very
likely to surprise us; in the mean time, however, I just want to
emphasise that [1] the problem is not easy when you move beyond a
specific locale and/or application domain (regular expressions won't
cut it for usability), and that [2] the solution will likely provide
less functionality than many people expect.


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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  Mon Nov 30 15:34:12 1998
From: anderst at toolsmiths.se (Anders W. Tell)
Date: Mon Jun  7 17:06:47 2004
Subject: Why XML data typing is hard
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk> <13922.44021.68599.496798@localhost.localdomain>
Message-ID: <3662BB43.3B36DFF3@toolsmiths.se>

david@megginson.com wrote:

> Michael Kay writes:
>
>  > "4,50" is a localized rendition of a float value. But in XML we
>  > should encourage a rendition-independent encoding of information.
>
> That is one of the biggest problems with applying concepts from data
> storage to syntax.  XML *is* pure external representation -- in a
> database, I can take any of the following appropriate to my locale and
> store it internally as the same bunch of bits:
>
>   4,5
>   4,50
>   4.5
>   4.50
>   004.500
>
> When I want to render that bunch of bits, I can pick any appropriate
> rendition based on the user's locale and formatting requests (for
> example, the user might have typed "4.50" into a field in a form, but
> the report for a French user might show "04,5").
>
> With XML, though, it is the representation itself that I'm exchanging,
> not the abstract data (though perhaps in the future people might want
> to pass around compiled DOM trees -- who knows?).  That means that if
> I put
>
>   <balance>4.50</balance>
>
> and send the document to a French user, the French user will still see
> the strange, foreign
>
>   <balance>4.50</balance>
>
> There's not a general-purpose, locale-independent way of storing it.

Why not ? The example above is your preferred interpretation of XML and
not how XML *may* be used. I personally accept many other views of XML.
Its up to the creator and the user of XML information to agree on the
interpretation.

One Design Pattern that I stongly support is the separation of Data and its
Presentation
and in the above example its the presentation that is sent, which is OK if the
user is a person but it the user an another computer its much better to send
the actual data (with formatting instructions if needed)
This is especially important in business to business communication that the
interpretation
of information is not uneccessary complex.


> You could define a local-independent text representation of a
> floating-point number, but then you're just adding yet another
> representation to the list.

Yes but having a *standard* data representation is making life easier for
everybody.
=> Less complexity
=> smaller application logic
=> Faster parsing, validation

>
> Please note that I'm *not* opposed to data typing: I think that it's
> necessary and that we will see something like it sooner or later.  I
> know that the XML Schema WG plans to work hard on data typing and that
> since there are many good, talented people in that WG, they are very
> likely to surprise us; in the mean time, however, I just want to
> emphasise that [1] the problem is not easy when you move beyond a
> specific locale and/or application domain (regular expressions won't
> cut it for usability), and that

Yes, but this applies only to Presentation and not  Data.
In most instances a number is a number is a number...

> [2] the solution will likely provide less functionality than many people
> expect.

Same a above comment.

I think Mike Kay has brought up many good points and I second the motion
of a *Data*  standard ontop of XML.

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


From creitzel at mediaone.net  Mon Nov 30 15:42:16 1998
From: creitzel at mediaone.net (Charles Reitzel)
Date: Mon Jun  7 17:06:47 2004
Subject: Why XML data typing isn't *too* hard
Message-ID: <199811301541.KAA02766@chmls06.mediaone.net>

NOTATIONS are perhaps the best way for XML authors to define appropriate
data types.  I think this is something Eliot K. has been talking about for
some time.  As David M. suggests, however, data types are often much more
constrained and application specific than just the C/Java primitive types.
I think of NOTATIONs as a way for the XML author to say, "the application
will know what to do with this", including applying constraints.  Agree w/
Eliot that NOTATION parameters would be helpful in this regard, e.g.
Decimal(10,2).

In analyzing a set of mainframe transaction "views" for conversion to XML I
wanted to use strong data typing but pure XML.  I came up w/ the following.
Any comments and criticisms would be appreciated.  Apologies for the length.

Some things to note: 

I do *not* include the protocol with the SYSTEM id's.  One client might use
http: or anonymous ftp: from a trusted system.  Others might use https: over
the public internet.

For this scheme to work properly, Namespaces should apply to notations and
entities as well as element names.  The usual rant applies about not being
able to specify the URI associated with DTD's or fragments thereof.

It is interesting that you can't define an enumeration for an element value,
only attributes.

I have made an effort to break up the DTD into reusable files, much as I
would with C++ header files.  I think the analogy is appropriate to this
application.  I hope this example illustrates to you "document" folks how us
"database" people view things - or at least this one does.

I miss parameterized macros a la the C preprocessor!

No linking in this app.  But if there were, ID/IDREF wouldn't work because
the <POSITION> has a compound key: acct# + cusip.  ID/IDREF is a pretty weak
form of linking.  Only useful if the ID's are generated, like Oracle
sequence #'s.  The difference is that ID's have document scope.  Sequence
#'s generally have table scope (probably found in many "documents").  Real
keys are more complicated.

Rather than names, the target system for these views uses the numeric tags
associated with each "field".  A #FIXED attribute does a good job of
associating numbers w/ the names.

===========================

<!-- acmeid.dtd Acme public identifiers -->
<!ENTITY % AcmePublicId     "Acme, Inc." >
<!ENTITY % AcmeIdPrefix     "-//%AcmePublicId;//Common" >

<!-- Non-parameter entity for use with namespace declarations -->
<!ENTITY Acme_Common_Namespace 
        "-//%AcmeIdPrefix;//Namespace version X.XXXX " 
>

===========================

<!-- acmetype.dtd Define Acme data types -->
<!ENTITY % AcmeIds
        SYSTEM "//xml.acme.com/common/acmeid.dtd" >
%AcmeIds;

<!ENTITY % AcmeDataTypePfx      "-//%AcmeIdPrefix;//DataType: " >

<!NOTATION ShareQuantity 
        PUBLIC "%AcmeDataTypePfx; ShareQuantity (12345678.12345)"
>
<!NOTATION SharePrice
        PUBLIC "%AcmeDataTypePfx; ShareQuantity (12345678.123)"
>
<!NOTATION Integer
        PUBLIC "%AcmeDataTypePfx; Integer"
>
<!NOTATION Float
        PUBLIC "%AcmeDataTypePfx; Float"
>
<!NOTATION Date
        PUBLIC "%AcmeDataTypePfx; Simple Date (YYYYMMDD)"
>
<!NOTATION Time
        PUBLIC "%AcmeDataTypePfx; Simple Time (23:59:59)"
>
<!NOTATION AlphaNum
        PUBLIC "%AcmeDataTypePfx; Alpha-Numeric"
>
<!NOTATION Indicator
        PUBLIC "%AcmeDataTypePfx; Indicator (Y/N)"
>

<!NOTATION AcmeDataType
        PUBLIC "%AcmeDataTypePfx; Data Type"
>

<!ENTITY % AcmeDataTypeList
"ShareQuantity|SharePrice|Integer|Float|Date|Time|AlphaNum|Indicator"
>
<!ENTITY % DataTypeDecl   "DataType NOTATION( %AcmeDataTypeList; ) #FIXED ">

<!ENTITY % AlphaNumAttr   "%DataTypeDecl; &#34;AlphaNum&#34;" >
<!ENTITY % IntegerAttr    "%DataTypeDecl; &#34;Integer&#34;" >
<!ENTITY % FloatAttr      "%DataTypeDecl; &#34;Float&#34;" >
<!ENTITY % DateAttr       "%DataTypeDecl; &#34;Date&#34;" >
<!ENTITY % TimeAttr       "%DataTypeDecl; &#34;Time&#34;" >
<!ENTITY % IndicatorAttr  "%DataTypeDecl; &#34;Indicator&#34;" >
<!ENTITY % ShareQtrAttr   "%DataTypeDecl; &#34;ShareQuantity&#34;" >
<!ENTITY % SharePriceAttr "%DataTypeDecl; &#34;SharePrice&#34;" >

===========================

<!-- acmeflds.dtd Acme "Field" Definitions -->

<!ENTITY % AcmeDataTypes
        SYSTEM "//xml.acme.com/common/acmetype.dtd" >
%AcmeDataTypes;

<!ENTITY % AcmeElemDefPfx       "-//%AcmeIdPrefix;//Element: " >
<!ENTITY % AcmeViewDefPfx       "-//%AcmeIdPrefix;//View: " >

<!ENTITY % FixedIntAttrDecl     " CDATA #FIXED " >
<!ENTITY % SizeAttr             "Size           %FixedIntAttrDecl;" >
<!ENTITY % AcmeTagAttr          "AcmeTag        %FixedIntAttrDecl;" >
<!ENTITY % MaxOccursAttr        "MaxOccurs      %FixedIntAttrDecl;" >


<!-- ATTRIBUTE COMMON TO MANY Acme VIEWS -->

<!ENTITY % ProdIdAttr
"PRODUCT_IDENTIFIER    ( A | B | C | D | E | F | G | I |
                         J | K | L | M | N | Q | R | S | 
                         T | U | V | W | X )  #REQUIRED"
>

<!ENTITY % VersionIdAttr
        "VERSION_IDENTIFIER_ID CDATA #IMPLIED"
>

<!ENTITY % ContKeyAttr
        "CONTINUATION_KEY CDATA #IMPLIED"
>


<!-- DEFINE THE FIELDS -->

<!ELEMENT INSTRUMENT_TYPE_ID (#PCDATA)>
<!ATTLIST INSTRUMENT_TYPE_ID
        %AlphaNumAttr;
        %SizeAttr;      "1"
        %AcmeTagAttr;   "1"
>
<!ELEMENT MARKET_VALUE_ID (#PCDATA)>
<!ATTLIST MARKET_VALUE_ID
        %FloatAttr;
        %SizeAttr;      "14"
        %AcmeTagAttr;   "298"
>
<!ELEMENT AS_OF_DATE (#PCDATA)>
<!ATTLIST AS_OF_DATE
        %DateAttr;
        %SizeAttr;      "8"
        %AcmeTagAttr;   "702"
>
<!ELEMENT BROKERAGE_ACCT_TYPE (#PCDATA)>
<!ATTLIST BROKERAGE_ACCT_TYPE
        %AlphaNumAttr;
        %SizeAttr;      "1"
        %AcmeTagAttr;   "703"
>
<!ELEMENT SETTLEMENT_DATE_SHARES (#PCDATA)>
<!ATTLIST SETTLEMENT_DATE_SHARES
        %AlphaNumAttr;
        %SizeAttr;      "15"
        %AcmeTagAttr;   "704"
>
<!ELEMENT TRADE_DATE_SHARES (#PCDATA)>
<!ATTLIST TRADE_DATE_SHARES
        %AlphaNumAttr;
        %SizeAttr;      "15"
        %AcmeTagAttr;   "705"
>
<!ELEMENT UNCOMMITTED_SHARES (#PCDATA)>
<!ATTLIST UNCOMMITTED_SHARES
        %AlphaNumAttr;
        %SizeAttr;      "15"
        %AcmeTagAttr;   "706"
>
<!ELEMENT BROKERAGE_CLOSING_PRICE (#PCDATA)>
<!ATTLIST BROKERAGE_CLOSING_PRICE
        %AlphaNumAttr;
        %SizeAttr;      "20"
        %AcmeTagAttr;   "708"
>
<!ELEMENT BROKERAGE_ACCT_NBR (#PCDATA)>
<!ATTLIST BROKERAGE_ACCT_NBR
        %AlphaNumAttr;
        %SizeAttr;      "9"
        %AcmeTagAttr;   "709"
>
<!ELEMENT BROKERAGE_CUSIP (#PCDATA)>
<!ATTLIST BROKERAGE_CUSIP
        %AlphaNumAttr;
        %SizeAttr;      "12"
        %AcmeTagAttr;   "740"
>
<!ELEMENT BROKERAGE_SYMBOL (#PCDATA)>
<!ATTLIST BROKERAGE_SYMBOL
        %AlphaNumAttr;
        %SizeAttr;      "12"
        %AcmeTagAttr;   "741"
>
<!ELEMENT SECURITY_DESCRIPTION (#PCDATA)>
<!ATTLIST SECURITY_DESCRIPTION
        %AlphaNumAttr;
        %SizeAttr;      "40"
        %AcmeTagAttr;   "745"
>
<!ELEMENT CORE_ACCOUNT_IND (#PCDATA)>
<!ATTLIST CORE_ACCOUNT_IND
        %AlphaNumAttr;
        %SizeAttr;      "1"
        %AcmeTagAttr;   "890"
>

===========================

<!-- Acme Document Type Definition (DTD) -->
<!-- Define Acme Brokerage Positions View FOV0001A -->

<!ENTITY % AcmeFields
        SYSTEM "//xml.acme.com/brokerage/acmeflds.dtd" >
%AcmeFields;

<!-- DEFINE THE VIEWS -->

<!ELEMENT FOV0001A_INPUT ( BROKERAGE_ACCT_NBR+ ) >
<!ATTLIST FOV0001A_INPUT
	xmlns			CDATA #FIXED "&Acme_Common_Namespace;"
        %ProdIdAttr;
        %VersionIdAttr;
        %ContKeyAttr;
        %MaxOccursAttr;         "6"
>
        
<!ELEMENT FOV0001A_POSITION 
      ( 
        INSTRUMENT_TYPE_ID |
	MARKET_VALUE_ID |
        AS_OF_DATE |
        BROKERAGE_ACCT_TYPE |
	SETTLEMENT_DATE_SHARES |
	TRADE_DATE_SHARES |
	UNCOMMITTED_SHARES |
	BROKERAGE_CLOSING_PRICE |
        BROKERAGE_ACCT_NBR |
	BROKERAGE_CUSIP |
	BROKERAGE_SYMBOL |
	SECURITY_DESCRIPTION |
	CORE_ACCOUNT_IND
      )
>
<!ATTLIST FOV0001A_POSITION
	BROKERAGE_ERROR_MSG_CODE  CDATA ""
	CONTINUATION_KEY	  CDATA ""
>

<!-- It's OK to #FIX the URI.  #FIX'ing the prefix bugs me -->

<!ELEMENT FOV0001A_OUTPUT ( FOV0001A_POSITION+ ) >
<!ATTLIST FOV0001A_OUTPUT
	xmlns			CDATA #FIXED "&Acme_Common_Namespace;"
	PAGE_OCCURRENCE_CNT	CDATA "000001"
	SECURITY_DESCRIPTOR	CDATA ""
>

===========================

<?xml version="1.0"?>
<!-- INPUT VIEW -->
<!DOCTYPE FOV0001A_INPUT PUBLIC 
        "-//Acme, Inc.//TEXT view FOV0001A INPUT//EN"
        "//xml.acme.com/brokerage/fov0001a.dtd"
>
<FOV0001A_INPUT 
	xmlns="&Acme_Common_Namespace;"
	PRODUCT_IDENTIFIER="X" 
	VERSION_IDENTIFIER_ID="2.3"
	CONTINUATION_KEY="123DFJIE9SMD9E9WEFE"
>
    <BROKERAGE_ACCT_NBR>X01362986</BROKERAGE_ACCT_NBR>
    <BROKERAGE_ACCT_NBR>H85859483</BROKERAGE_ACCT_NBR>
</FOV0001A_INPUT>

===========================

<?xml version="1.0"?>
<!-- OUTPUT VIEW -->
<!DOCTYPE FOV0001A_OUTPUT PUBLIC 
        "-//Acme, Inc.//VIEW FOV0001A OUTPUT//EN"
        "//xml.acme.com/brokerage/fov0001a.dtd"
>
<FOV0001A_OUTPUT 
	xmlns="&Acme_Common_Namespace;"
	PAGE_OCCURRENCE_CNT="000002"
>
    <FOV0001A_POSITION>
	<INSTRUMENT_TYPE_ID>1</INSTRUMENT_TYPE_ID>
	<MARKET_VALUE_ID>23.50</MARKET_VALUE_ID>
	<AS_OF_DATE>19980716</AS_OF_DATE>
	<BROKERAGE_ACCT_TYPE>Z</BROKERAGE_ACCT_TYPE>
	<SETTLEMENT_DATE_SHARES>3442.12500</SETTLEMENT_DATE_SHARES>
	<TRADE_DATE_SHARES>3442.12500</TRADE_DATE_SHARES>
	<UNCOMMITTED_SHARES>0.00000</UNCOMMITTED_SHARES>
	<BROKERAGE_CLOSING_PRICE>13.125</BROKERAGE_CLOSING_PRICE>
	<BROKERAGE_ACCT_NBR>X01362986</BROKERAGE_ACCT_NBR>
	<BROKERAGE_CUSIP>ABCDEFGHIJ</BROKERAGE_CUSIP>
	<BROKERAGE_SYMBOL>BUD</BROKERAGE_SYMBOL>
	<SECURITY_DESCRIPTION>Anheuser-Busch, Inc.</SECURITY_DESCRIPTION>
	<CORE_ACCOUNT_IND>Y</CORE_ACCOUNT_IND>
    </FOV0001A_POSITION>
    <FOV0001A_POSITION>
	<INSTRUMENT_TYPE_ID>1</INSTRUMENT_TYPE_ID>
	<MARKET_VALUE_ID>6788.50</MARKET_VALUE_ID>
	<AS_OF_DATE>19980811</AS_OF_DATE>
	<BROKERAGE_ACCT_TYPE>Z</BROKERAGE_ACCT_TYPE>
	<SETTLEMENT_DATE_SHARES>8446.25000</SETTLEMENT_DATE_SHARES>
	<TRADE_DATE_SHARES>8446.25000</TRADE_DATE_SHARES>
	<UNCOMMITTED_SHARES>0.00000</UNCOMMITTED_SHARES>
	<BROKERAGE_CLOSING_PRICE>131.250</BROKERAGE_CLOSING_PRICE>
	<BROKERAGE_ACCT_NBR>H85859483</BROKERAGE_ACCT_NBR>
	<BROKERAGE_CUSIP>JEUYRU88392</BROKERAGE_CUSIP>
	<BROKERAGE_SYMBOL>ATT</BROKERAGE_SYMBOL>
	<SECURITY_DESCRIPTION>AT&amp;T, Inc.</SECURITY_DESCRIPTION>
	<CORE_ACCOUNT_IND>Y</CORE_ACCOUNT_IND>
    </FOV0001A_POSITION>
</FOV0001A_OUTPUT>

===========================

Regards,
Charles Reitzel
creitzel@mediaone.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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 dns.isogen.com  Mon Nov 30 16:38:05 1998
From: eliot at dns.isogen.com (W. Eliot Kimber)
Date: Mon Jun  7 17:06:47 2004
Subject: Why XML data typing is hard 
In-Reply-To: <13922.44021.68599.496798@localhost.localdomain>
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>
 <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <3.0.5.32.19981130103657.00933b40@amati.techno.com>

At 09:43 AM 11/30/98 -0500, david@megginson.com wrote:
>Michael Kay writes:
>
> > "4,50" is a localized rendition of a float value. But in XML we
> > should encourage a rendition-independent encoding of information.
>
>That is one of the biggest problems with applying concepts from data
>storage to syntax.  XML *is* pure external representation -- in a
>database, I can take any of the following appropriate to my locale and
>store it internally as the same bunch of bits:

I observe that in the SGML Extended Facilities (part of ISO/IEC
10744:1997), we expressly defined a mechanism for *lexical* typing of
attributes and content, although our original idea was to define a
mechanism for *data* typing. This is because we realized that at the syntax
level all we can talk about meaningfully is spelling rules, not semantic
rules.

In the Web SGML TC, we have added the ability to associate notations with
particular attributes, to indicate that the interpretation of the value is
governed by a particular notation. This is one way to get data typing, that
is, the translation of a particular syntactic expression into a semantic
object.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Mon Nov 30 16:41:45 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:48 2004
Subject: Internal subset equivalent in new schema proposals?
References: <199811280553.AAA05471@locke.ccil.org> <366015BA.AFB7C044@prescod.net>
Message-ID: <3662CAA7.CC805552@locke.ccil.org>

Paul Prescod scripsit:

> That's fine, but it isn't clear why XML must be able to support directed
> graphs at its most basic level.

Because all the world isn't a hierarchy, and sometimes the hierarchical
aspect of things is its least important aspect.  Obviously, anything
that is supported in the core could be migrated to an outer layer,
as we are seeing with schema languages.  Indeed in a sense ID/IDREF
support is not in the *core* core, because NVPs don't have to
recognize them.

> We also know that one of the requirements for supporting directed graphs
> *properly* is the ability to do relative addressing (that's why we have
> XPointer).

I don't agree, unless proper support is equated with support that is
robust against change, which is a Good Thing, but not the Only Good
Thing.  Sometimes crude and fast is better than general.

> ID/IDREF also has a very inflexible
> namespace mechanism. Strictly speaking it is "enough" in that every
> element is addressable, but practically speaking it does not allow us to
> express the structure explicitly enough.

IMHO IDs should never carry semantic information: they should always
be arbitrary unique values.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From begeddov at jfinity.com  Mon Nov 30 17:09:09 1998
From: begeddov at jfinity.com (Gabe Beged-Dov)
Date: Mon Jun  7 17:06:48 2004
Subject: XML and embedded compound data types (was "Why XML data typin is hard")
Message-ID: <004601be1c84$14d6e100$160016c0@jfinity1>

I have been reading the latest postings on XML data typing and want to throw
out a different viewpoint. several caveats are that I haven't perused all of
the archives to see if I'm tramping down well-worn paths. I am also much
more interested in the non-prose uses of XML so take that into account.

The perspective is the possibly naive one that XML can/should be used to
capture ALL of the structural aspects of a complex tree of data. Wherever a
compound type occurs in the source data, it should be mapped to a
corresponding compound type in XML.  A key heuristic to see if this approach
is being adhered to is to see if any attribute  values or character data
requires additional parsing by the application in order to deserialize
additional structure.

In the case of a date or float, I would argue that they are both compound
types and should be represented as such. If this approach is chosen, you can
end up using integers and enumerations (as long as you use attributes). This
is obviously much more verbose, but cleanly separates content from
presentation. I forget which of the many schema proposals used this approach
but at least one did.  If you adhere to this approach, alot of the issues of
providing inline support for validation of character data (that will require
additional parsing by the application) goes away.

Many issues of data typing remain, such as how to recognize a valid country
name, but these are not structural issues related to compound types hiding
inside a human readable serialization  format.

Gabe Beged-Dov
www.jfinity.com





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From jbolles at homeaccount.com  Mon Nov 30 17:25:13 1998
From: jbolles at homeaccount.com (Jack Bolles)
Date: Mon Jun  7 17:06:48 2004
Subject: Sun's XML Classes
References: <773251A595CFD111B8F800A0C998C55102CF93@ris3.robco-inc.com>
Message-ID: <3662D565.30C3329A@homeaccount.com>

Without looking at the Sun classes, or knowing the class that can call appendChild(), I would start with this:

//assuming "billTo" is a class variable
private void appendNewChild(Object billToObject, String sourceField) {
        billTo.appendChild(billToObject);
        billTo.appendChild(new TextNode("\n"));
        billToObject.appendChild(doc.createTextNode(sourceField));
}

Regards,
Jack Bolles
--
"A Java strategy without an XML strategy is incomplete," - Eric Brown, Forrester 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 30 18:00:13 1998
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:06:48 2004
Subject: Why XML data typing is hard
In-Reply-To: 's message of "Mon, 30 Nov 1998 09:43:35 -0500 (EST)"
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk> <13922.44021.68599.496798@localhost.localdomain>
Message-ID: <f5b3e71oycq.fsf@cogsci.ed.ac.uk>

<david@megginson.com> writes:

> [bits elided]
>
> With XML, though, it is the representation itself that I'm exchanging,
> not the abstract data (though perhaps in the future people might want
> to pass around compiled DOM trees -- who knows?).  That means that if
> I put
> 
>   <balance>4.50</balance>
> 
> and send the document to a French user, the French user will still see 
> the strange, foreign
> 
>   <balance>4.50</balance>

Basically I agree that we're not talking datatypes, we're talking
lexical types (see Eliot's reply as well), but there is one
observation I'd like to add here.

Is this situation actually any different from the case where I write

<balance>four fifty</balance>

?

In other words, if there are (natural) language/culture dependent
aspects to our documents, then if we are good citizens we should use
the xml:lang attribute to signal this.  This is NOT the same as (see
some earlier messages) expecting the PROCESSOR's locale to sort things 
out:  it's more like including the AUTHOR's locale in the document.

So just as I might write

<balance xml:lang='fr'>quatre cinquante</balance>

if we add sensitivity to language to our lexical typing, I might write

<balance xml:lang='fr'>4,50</balance>

OR

<balance xml:lang='ar'>&#x0664;&#x066B;&#x0665;&#0660;</balance>

Is the latter an indication of a plausable way forward, i.e. lexical
types which are parameterised by (natural) language?

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 30 18:18:57 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:48 2004
Subject: XML and embedded compound data types (was "Why XML data typin is hard")
References: <004601be1c84$14d6e100$160016c0@jfinity1>
Message-ID: <3662E166.BA58E220@locke.ccil.org>

Gabe Beged-Dov wrote:

> I have been reading the latest postings on XML data typing and want to throw
> out a different viewpoint. several caveats are that I haven't perused all of
> the archives to see if I'm tramping down well-worn paths.

Not well-worn, but not utterly novel either.

> The perspective is the possibly naive one that XML can/should be used to
> capture ALL of the structural aspects of a complex tree of data. Wherever a
> compound type occurs in the source data, it should be mapped to a
> corresponding compound type in XML.  A key heuristic to see if this approach
> is being adhered to is to see if any attribute  values or character data
> requires additional parsing by the application in order to deserialize
> additional structure.

A compromise which I proposed --- to resounding denunciation from all
(then existing) quarters --- was a facility overlaid on XML which would
remap specific local syntax characters, when found within the character
content of specified elements, to empty element tags.  Thus, given the
following XML:

	<?map map1 ":" colon?>
	<?map map1 "T" time?>
	<?map map1 "-" dash?>
	<?map map1 "." dot?>
	<?apply-map map1 date?>
	...
	<date>1998-04-05T15:22:23.24</date>

the application would receive the SAX or DOM equivalent of:

	<date>1998<dash/>04<dash/>05<time/>
		15<colon/>22<colon/>23<dot/>24</date>

This is level 1 of my "Local Markup" proposal; level 2 provides
for nested as well as empty tags generated by characters,
by allowing for prioritization of local markup characters.
Only single characters are supported, but since there are
65000 of them, that should be sufficient.

SGML had something like this, but much more powerful/flexible/
hard to parse.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From paul at prescod.net  Mon Nov 30 18:24:34 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:48 2004
Subject: XML and embedded compound data types (was "Why XML data typin is 
 hard")
References: <004601be1c84$14d6e100$160016c0@jfinity1>
Message-ID: <3662D6ED.75AD0C5B@prescod.net>

Gabe Beged-Dov wrote:
> 
> The perspective is the possibly naive one that XML can/should be used to
> capture ALL of the structural aspects of a complex tree of data. Wherever a
> compound type occurs in the source data, it should be mapped to a
> corresponding compound type in XML.  

What is the "source data?" XML is a language description tool. It is not a
database serialization tool. In many cases the "source data" is my head.
XML happens to be useful as a database serialization tool because
databases are simpler than the stuff I have in my head.

> A key heuristic to see if this approach
> is being adhered to is to see if any attribute  values or character data
> requires additional parsing by the application in order to deserialize
> additional structure.

XML allows us to design languages that are palatable for human beings.
That is its only technical advantage over an S-Expression-based
equivalent. You can remove the "flaw" of human orientation by requiring
everything to be explicitly expanded, but you will also destroy XML as a
language. It will be as unreadable and untypeable as its competitors and
will be ignored just as they are.

Just out of curiousity, here are some of the XML-related specs that fail
according to your heuristic:

 * XPointer
 * XML Namespaces
 * XSL

and of course any specification built *on top* of these.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Mon Nov 30 18:28:02 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:48 2004
Subject: Why XML data typing is hard
In-Reply-To: <f5b3e71oycq.fsf@cogsci.ed.ac.uk>
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>
	<13922.44021.68599.496798@localhost.localdomain>
	<f5b3e71oycq.fsf@cogsci.ed.ac.uk>
Message-ID: <13922.57337.733783.954801@localhost.localdomain>

Henry S. Thompson writes:

 > if we add sensitivity to language to our lexical typing, I might write
 > 
 > <balance xml:lang='fr'>4,50</balance>
 > 
 > OR
 > 
 > <balance xml:lang='ar'>&#x0664;&#x066B;&#x0665;&#0660;</balance>
 > 
 > Is the latter an indication of a plausable way forward, i.e. lexical
 > types which are parameterised by (natural) language?

It sounds quite plausible: it still places a burden of locale handling
on the processor or the application, but that's inevitable when we're
dealing with lexical constraints.  At least with this approach the
application will be able to fail gracefully:

  Warning: sample.xml line 18 column 12: Cannot validate constraint
           "float" for unsupported language "ar" (trying default
           locale en-CA).

(That's not "Californian English", by the way.)


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


From tms at ansa.co.uk  Mon Nov 30 18:28:07 1998
From: tms at ansa.co.uk (Toby Speight)
Date: Mon Jun  7 17:06:48 2004
Subject: Why XML data typing is hard
In-Reply-To: ht@cogsci.ed.ac.uk's message of "30 Nov 1998 17:59:49 +0000"
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk> <13922.44021.68599.496798@localhost.localdomain> <f5b3e71oycq.fsf@cogsci.ed.ac.uk>
Message-ID: <u90gtavea.fsf@delivery.ansa.co.uk>

Henry> Henry S. Thompson <URL:mailto:ht@cogsci.ed.ac.uk>

0> In article <f5b3e71oycq.fsf@cogsci.ed.ac.uk>, Henry wrote:

Henry> In other words, if there are (natural) language/culture dependent
Henry> aspects to our documents, then if we are good citizens we should
Henry> use the xml:lang attribute to signal this.  This is NOT the same
Henry> as (see some earlier messages) expecting the PROCESSOR's locale
Henry> to sort things out: it's more like including the AUTHOR's locale
Henry> in the document.
Henry>
Henry> So just as I might write
Henry>
Henry> <balance xml:lang='fr'>quatre cinquante</balance>
Henry>
Henry> if we add sensitivity to language to our lexical typing, I
Henry> might write
Henry>
Henry> <balance xml:lang='fr'>4,50</balance>
Henry>
Henry> OR
Henry>
Henry> <balance xml:lang='ar'>&#x0664;&#x066B;&#x0665;&#0660;</balance>
Henry>
Henry> Is the latter an indication of a plausable way forward,
Henry> i.e. lexical types which are parameterised by (natural)
Henry> language?

It looks attractive at first sight, but think of the burden you're
placing on processors - instead of authors having to transform from
their *own* locale to a canonical representation, readers have to
transform from the *document's* (arbitrary) locale.  So readers now
need to know (enough about) *all* the locales from which they might
receive data.

Note that I'm considering the issues from the point of view of an
interchange format.  I've no objection to the use of the above in an
internal, single-language environment, as long as the elements are
transformed to a canonical form when passed to unsuspecting readers.

-- 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From paul at prescod.net  Mon Nov 30 18:32:12 1998
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun  7 17:06:48 2004
Subject: Internal subset equivalent in new schema proposals?
References: <199811280553.AAA05471@locke.ccil.org> <366015BA.AFB7C044@prescod.net> <3662CAA7.CC805552@locke.ccil.org>
Message-ID: <3662D47D.8EF9E2CA@prescod.net>

John Cowan wrote:
> 
> Paul Prescod scripsit:
> 
> > That's fine, but it isn't clear why XML must be able to support directed
> > graphs at its most basic level.
> 
> Because all the world isn't a hierarchy, and sometimes the hierarchical
> aspect of things is its least important aspect.  

No, not all of the world is a hierarchy, but there is something to be said
for supporting different data models in different logical levels.
Separating them out allows you to think them through better and do a
better job (e.g. XPointer vs. ID/IDREF).

> Obviously, anything
> that is supported in the core could be migrated to an outer layer,
> as we are seeing with schema languages.  Indeed in a sense ID/IDREF
> support is not in the *core* core, because NVPs don't have to
> recognize them.

Another good reason to ignore them and use something at the XPointer
level.

> > We also know that one of the requirements for supporting directed graphs
> > *properly* is the ability to do relative addressing (that's why we have
> > XPointer).
> 
> I don't agree, unless proper support is equated with support that is
> robust against change, which is a Good Thing, but not the Only Good
> Thing.  Sometimes crude and fast is better than general.

If XPointer is widely supported, it will be just as fast to use an
XPointer. You can make it crude if you want, also.

> > ID/IDREF also has a very inflexible
> > namespace mechanism. Strictly speaking it is "enough" in that every
> > element is addressable, but practically speaking it does not allow us to
> > express the structure explicitly enough.
> 
> IMHO IDs should never carry semantic information: they should always
> be arbitrary unique values.

If I have an element that teaches a topic, and I give it an ID, and then I
delete that chapter, but there is another chapter that could also teach
the topic, shouldn't I be able to transfer the ID? (XML does not let me do
it if the new chapter already has an ID.) Obviously, my choice of new ID
for the second element is not arbitrary.

Anyhow, whether names are arbitrary or not, the real problem is that there
is only one ID namespace when we really need many of them. IDs name an
element, but elements can need multiple names, just as anything else can.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself.
 http://itrc.uwaterloo.ca/~papresco

Christmas shopping in a T-Shirt? Toto, I have a feeling we 
aren't in Canada anymore.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Mon Nov 30 18:34:55 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:48 2004
Subject: XML and embedded compound data types (was "Why XML data typin is 
	 hard")
References: <004601be1c84$14d6e100$160016c0@jfinity1> <3662D6ED.75AD0C5B@prescod.net>
Message-ID: <3662E4B1.F7DC0AB6@locke.ccil.org>

Paul Prescod wrote:

> XML allows us to design languages that are palatable for human beings.

My proposed LocalMarkupFilter allows us to design languages that
are palatable for human beings (with syntax appropriate to a given
notation), but processable using only XML parser events, with no
second-order parser (technically, no second-order *lexer*) required.

> Just out of curiosity, here are some of the XML-related specs that fail
> according to your heuristic:
> 
>  * XPointer
>  * XML Namespaces
>  * XSL

Also URIs and URI references in general.
 
-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From cowan at locke.ccil.org  Mon Nov 30 18:44:59 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:48 2004
Subject: Internal subset equivalent in new schema proposals?
References: <199811280553.AAA05471@locke.ccil.org> <366015BA.AFB7C044@prescod.net> <3662CAA7.CC805552@locke.ccil.org> <3662D47D.8EF9E2CA@prescod.net>
Message-ID: <3662E739.1A5B4F62@locke.ccil.org>

Paul Prescod wrote:

> If I have an element that teaches a topic, and I give it an ID, and then I
> delete that chapter, but there is another chapter that could also teach
> the topic, shouldn't I be able to transfer the ID?

IMO no.  Two objects with the same ID are really the *same* object,
not just equivalent for a specified purpose.  (To a learner, your
chapters might be equivalent; to a bibliographer, they wouldn't be.)

> Anyhow, whether names are arbitrary or not, the real problem is that there
> is only one ID namespace when we really need many of them. IDs name an
> element, but elements can need multiple names, just as anything else can.

Yes, but IDs aren't the way to model user-friendly names.  This
email has many "names", but only one Message-ID, which is as it should
be; that Message-ID is globally unique unless there are bugs somewhere.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From tbray at textuality.com  Mon Nov 30 18:51:00 1998
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun  7 17:06:48 2004
Subject: Why XML data typing is hard
Message-ID: <3.0.32.19981130105028.00bb1a60@pop.intergate.bc.ca>

At 05:59 PM 11/30/98 +0000, Henry S. Thompson wrote:
>Basically I agree that we're not talking datatypes, we're talking
>lexical types 
...
>Is the latter an indication of a plausable way forward, i.e. lexical
>types which are parameterised by (natural) language?

It's good that we're distinguishing between lexical types and datatypes.
With real datatypes, it seems that we ought to be able to hard-wire
the syntax - i.e. say that for FIXED or FLOAT data types, the following
decimal delimiter is always used, for DATE it's always ISO8601, and
so on.  The idea being that this kind of thing, in a production type
app, is going to be run through software machinery at both ends, such
that on the screen, a Francophone will see 4,50 and and Anglophone 4.50, 
so it doesn't matter that much what's between the tags.  

It seems to me that this kind of hardwired datatyping is in greater
short-term demand and is also easier to implement efficiently than
lexical typing, thus that's where I'd start; but reasonable people
may disagree. -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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From M.H.Kay at eng.icl.co.uk  Mon Nov 30 18:54:35 1998
From: M.H.Kay at eng.icl.co.uk (Michael Kay)
Date: Mon Jun  7 17:06:48 2004
Subject: XML and embedded compound data types (was "Why XML data typin is hard")
Message-ID: <004001be1c91$f3498570$7008e391@bra01wmhkay.bra01.icl.co.uk>

>In the case of a date or float, I would argue that they are both compound
>types and should be represented as such.

The popular human representations of dates and floats are compound, but the
intrinsic values are not. They are both points in a one-dimensional space,
the first being discrete and the second pseudo-continuous.

It is possible to choose representations of float and date that require no
parsing to extract, process, or render (localize) the value. I think there
is some merit in choosing a canonical XML representation of dates and floats
that is meaningful to a good proportion of people on the planet, but it is
more important that it is canonical.

In practice I would always recommend ISO 8601 representation for dates. This
is better than using a Julian day number because it is more meaningful to
humans. The parsing of this is so trivial that using XML tagging would not
add value, either for the human reader or the machine recipient.

Mike Kay




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From david at megginson.com  Mon Nov 30 18:54:57 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:48 2004
Subject: Why XML data typing is hard
In-Reply-To: <u90gtavea.fsf@delivery.ansa.co.uk>
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk>
	<13922.44021.68599.496798@localhost.localdomain>
	<f5b3e71oycq.fsf@cogsci.ed.ac.uk>
	<u90gtavea.fsf@delivery.ansa.co.uk>
Message-ID: <13922.59380.307671.802609@localhost.localdomain>

Toby Speight writes:

 > Note that I'm considering the issues from the point of view of an
 > interchange format.  I've no objection to the use of the above in
 > an internal, single-language environment, as long as the elements
 > are transformed to a canonical form when passed to unsuspecting
 > readers.

I don't think that anyone's disagreeing that a standard lexical
interchange format can be useful; the question is where it should be
standardised: at the general XML level, or at the XML-based
specification level?  In other words, should there be a collection of
one-size-fits-all interchange formats that all XML-based specs have to
use, or should each spec be free to adapt its own?

Or to put this yet another way, why don't we standardise on ',' for
the decimal (and currency) separator in XML?

  <price currency="USD">4,55</price>

You could always render using '.' if the locale demanded 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 30 19:00:12 1998
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun  7 17:06:49 2004
Subject: XML and embedded compound data types (was "Why XML data typin is hard")
References: <004001be1c91$f3498570$7008e391@bra01wmhkay.bra01.icl.co.uk>
Message-ID: <3662EA9F.6AF5EA03@locke.ccil.org>

Michael Kay wrote:

> In practice I would always recommend ISO 8601 representation for dates. This
> is better than using a Julian day number because it is more meaningful to
> humans. The parsing of this is so trivial that using XML tagging would not
> add value, either for the human reader or the machine recipient.

I assume you mean a simple subset of 8601 rather than the whole
representation standard.  My choosing an 8601 date as an example for
LocalMarkupFilter was meant for simplicity and ease of understanding,
not as a practical use case.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From andrewl at microsoft.com  Mon Nov 30 19:27:27 1998
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun  7 17:06:49 2004
Subject: Embedded vCard
Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEB31@RED-MSG-08>

XML Namespaces (http://www.w3.org/TR/PR-xml-names) is designed to allow the
sort of combination that you show in your example:

<? xml version="1.0" ?>
<answer xmlns="answer.dtd" xmlns:vcrd="vCard.dtd">
	<caller>
		<vcrd:vCard version="3.0">
		    <vcrd:fn>Milla</vcrd:fn>
		</vcrd:vCard>
	</caller>
</answer>

The exact values you show for the attributes xmlns and xmlns:vcrd are not
accurate, however.  Both need to be URIs.  While it is easily possible for
you to create your own URI for 'answer,' if you want interoperability with
other programs that will recognize the vcard namespace, you will need some
common agreement on the name of the namespace for the vcard elements.
Technically, this does not need to be a URI issued by the organization
controlling vCard; it could be a URI merely recognized by you and whatever
other programs you interoperate with; but it would obviously be beneficial
to have a single, widely-used URI.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From bryan.cooper at veritas.com  Mon Nov 30 19:30:22 1998
From: bryan.cooper at veritas.com (Bryan Cooper)
Date: Mon Jun  7 17:06:49 2004
Subject: Default Namespace should be clearly documented and supported
  by specific <TAG> type
Message-ID: <199811301928.LAA06695@mailhub1.ncal.verio.com>

Some of my email was eaten up on the way out.
I am resending these comments to hopefully make some sort of sense,
assuming they made some sort of sense in the first place...thanx

I would like the namespace specification to show examples of how to
switch the default namespace using a clear tagging convention.  
I'd REALLY like to see a generalized <!EVENT> notation used
for that tagging convention.

I'd like to see an example of how to do the following:

< HTML>
< P>
<different_ns:push_new_context_for_namespace_example>
< P>
< /different_ns:push_new_context_for_namespace_example>
</HTML>

In the DTD, I'd like to see this type of syntax:

< !EVENT push_new_context_for_namespace_example xnmls="different_ns"
TYPE="push"/>

The first < P> MUST BE < HTML>, and
the second < P> would be automatically
default namespace parsed as belonging to the 2nd namespace different_ns.  
It wouldn't require in the DTD any namespace declarations so the
parser wouldn't need to check namespace for every TAG in the document.
The parser would merely push the current default using this EVENT TAG.

This approach simplifies the need to tag ENTITIES
at all, but instead lets the parser know which default namespace
is in effect.   I am concerned that the specification requires ENTITIES to
change
the namespace, when in fact a parser directed command is really preferable.
I think otherwise all ENTITIES are going to have namespace overhead in
their DTD.
I think the parser will then spend too much time determining which namespace
each TAG uses.  Or maybe the spec doesn't allow namespace declaration in
the DTD.
That would be VERY difficult to support since then the application creating
the 
doc would probably put namespace declarations on every doc TAG.  That's
alot of overhead.

The EVENT is a new type of entity and the TYPE statement 
could become more explicit in XML over time to support different types 
of parser specific tweaks.  THe idea is to allow the DTD to define
a specific TAG that pushes the namespace context until end of TAG.

I assume I could use an ENTITY for this but then I should have the ENTITY
cover all the possible ENTITIES in the DTD in terms of encapsulation.
An EVENT type would NOT require encapsulation of ENTITIES, but rather
would be clearly a parser directed command.

Is this supported by the draft?  It wasn't clear from the example
that a namespace change tag is supported by the DTD as a specific type of 
"switch default namespace tag", but I think it is available.  I'd just like to
see it clearly documented in the spec, and I am suggesting the EVENT
addition to XML as a means of making it even more explicit.  

The DTD should clearly allow the definition of the context switch
tag in "different_ns" such as shown above in 
< different_ns: push_new_context_for_namespace_example>.

These tags would be then be the only tags requiring the namespace prefix,
since all included tags must then be supported by the "different_ns",
UNLESS they include a different namespace prefix.  In fact, the
use of the different namespace prefix is just a one time example
of pushing the context to a different namespace.  The example in
the spec implies that all enclosed tags will be in the different
namespace.  It should also show that specified namespace
prefix tags do NOT cause such as shift, but rather are one time only
for the TAG:

< HTML>
< different_ns:P>
< P> in HTML
< /HTML>

 
...bryan

F. Bryan Cooper	 		707 823 7324 
VERITAS Software      		707 321 3301 mobile
Bryan.Cooper@veritas.com   

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From begeddov at jfinity.com  Mon Nov 30 19:39:10 1998
From: begeddov at jfinity.com (Gabe Beged-Dov)
Date: Mon Jun  7 17:06:49 2004
Subject: XML and embedded compound data types (was "Why XML data typin is hard")
Message-ID: <002c01be1c99$14ad5370$160016c0@jfinity1>

>What is the "source data?" XML is a language description tool. It is not a
>database serialization tool. In many cases the "source data" is my head.
>XML happens to be useful as a database serialization tool because
>databases are simpler than the stuff I have in my head.

This seems to be one of the many dimensions along which people diverge in
their interpretation of "What is XML", i.e. human centric vs. data centric.
I have experienced enough of these philosophical discussions, both first
hand, and as an observer on this and other forums, to hope to steer towards
less turbulent waters.

>Just out of curiousity, here are some of the XML-related specs that fail
>according to your heuristic:
>
> * XPointer
> * XML Namespaces
> * XSL


My impression is that namespaces should be seen as part of the core syntax
of XML. The application should not need to parse namespace information out
of the data handed it by the processor.

It is true that XSL and XPointer bring their own parsing requirements to the
table. On the other hand, it seems that an attempt has been made, wherever
possible, to use the structural facilities of XML in lieu of other syntax.

My primary intent was to flag the fact that compound types should be
explicity decomposed when mapped to XML.  Michael Kay (and many others) have
brought up the concept of canonical representations as the interchange
format. Pragmatism argues for reusing existing canonical representations
such as ISO 8601.  In order for this to meet my "no parse" rule, it would
require a conforming processor, and internal representations like DOM, to
support all these compound types.

An alternative is to push it up a level, like many people have suggested,
but with the nuance that you strongly encourage/enforce that prescription
that no additional structure should be hidden in the document that requires
application parsing.

Gabe Beged-Dov
www.jfinity.com






xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From liamquin at interlog.com  Mon Nov 30 20:49:08 1998
From: liamquin at interlog.com (Liam R. E. Quin)
Date: Mon Jun  7 17:06:49 2004
Subject: Why XML data typing is hard
In-Reply-To: <3.0.32.19981130105028.00bb1a60@pop.intergate.bc.ca>
Message-ID: <Pine.BSI.3.96r.981130154456.8189C-100000@shell1.interlog.com>

Henry S. Thompson writes:
> if we add sensitivity to language to our lexical typing, I might write
>
> <balance xml:lang='fr'>4,50</balance>
> <balance xml:lang='ar'>&#x0664;&#x066B;&#x0665;&#0660;</balance>
[...]

david@megginson.com wrote:
> It sounds quite plausible: it still places a burden of locale handling
> on the processor or the application, but that's inevitable when we're
> dealing with lexical constraints.  At least with this approach the
> application will be able to fail gracefully:
>

>   Warning: sample.xml line 18 column 12: Cannot validate constraint
>            "float" for unsupported language "ar" (trying default
>            locale en-CA).
>

Where did the word "float" come from in that error message?

Is it part of an augmented DTD or Schema, or a stylesheet, or is it
wired in to the application?

Maybe what you really need is
    <balance xml:type="float" xml:lang='ar'> ...
instead?

Lee

--
Liam Quin, GroveWare Inc., the barefoot programmer
l i a m q u i n   at   i n t e r l o g   dot   c o 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From db at Eng.Sun.COM  Mon Nov 30 21:06:50 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:49 2004
Subject: Sun's XML Classes
References: <773251A595CFD111B8F800A0C998C55102CF93@ris3.robco-inc.com>
Message-ID: <3663075F.541CF451@eng.sun.com>

Rob Williams wrote:
> 
> I downloaded the Early Access of the Sun classes and they work ok, so far
> for what I've wanted to do with them. My question is, has anyone else found
> that you end up writing a lot of ugly code to get simple things done?

That's basically what you get from using the W3C APIs directly.  Some of
what you're doing is more or less pretty-printing ... which the next
version will do for you automatically.

Also, as noted, helper methods are not only Your Good Friends but are
generally good style anyway!

- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 30 21:30:33 1998
From: david at megginson.com (david@megginson.com)
Date: Mon Jun  7 17:06:49 2004
Subject: Why XML data typing is hard
In-Reply-To: <Pine.BSI.3.96r.981130154456.8189C-100000@shell1.interlog.com>
References: <3.0.32.19981130105028.00bb1a60@pop.intergate.bc.ca>
	<Pine.BSI.3.96r.981130154456.8189C-100000@shell1.interlog.com>
Message-ID: <13923.3539.599766.829514@localhost.localdomain>

Liam R. E. Quin writes:

 > david@megginson.com wrote:

 [...]

 > >   Warning: sample.xml line 18 column 12: Cannot validate constraint
 > >            "float" for unsupported language "ar" (trying default
 > >            locale en-CA).
 > >
 > 
 > Where did the word "float" come from in that error message?
 > 
 > Is it part of an augmented DTD or Schema, or a stylesheet, or is it
 > wired in to the application?
 > 
 > Maybe what you really need is
 >     <balance xml:type="float" xml:lang='ar'> ...
 > instead?

That's almost exactly the markup that I was imagining would generate
the warning, except that I'd use a different namespace for the lexical
constraint attribute (no need to overload the magic "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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From sroth at radsys.com  Mon Nov 30 21:33:30 1998
From: sroth at radsys.com (Roth, Scott)
Date: Mon Jun  7 17:06:49 2004
Subject: Hyperlink in XML
Message-ID: <5FAFB2A5D7B2D111ACEA0060972027CE186416@RADSYS_EXCH>

Below is a sample of my XML data. I am curious to how I get the PanelListID
data to show up as a hyperlink.  When I look at the file in the browswer it
just has 5678, but no hyperlink.  Could somebody please help this
newbie....?

Thanks,
Scott Roth


<FILE>
      
    <Workflow>FILE CLUSTER</Workflow>       
     
        
    <FileID>1234</FileID>     
    <PanelListID><a href="http://www.yahoo.com">5678</a></PanelListID> 
    <Date>
       <Day>13</Day>
       <Year>1998</Year>
       <Month>4</Month>
    </Date>     
   
  </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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 30 21:49:59 1998
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun  7 17:06:49 2004
Subject: Non-validating parser behavior
Message-ID: <199811302149.QAA30823@hesketh.net>

As has been discussed on this list previously (see
http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0019.html), non-validating
parsers are not required to load external DTD information (as discussed in
section 4.4.3 and elsewhere in the spec.)  This was done, supposedly, to make
it easier to display information gathered from the Web without making the user
wait for external resources to be fetched before display or processing could
begin.

Are there any non-validating parsers that actually behave this way?  Lark and
Aelfred have both fetched external DTD subsets without a question, and I
haven't noticed anything to suggest otherwise in the non-validating parsers
I've looked at so far.

Just curious! 

Simon St.Laurent
XML: A Primer / Cookies
Sharing Bandwidth (December)
Building XML Applications (January)
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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From rob at robco-inc.com  Mon Nov 30 22:42:41 1998
From: rob at robco-inc.com (Rob Williams)
Date: Mon Jun  7 17:06:49 2004
Subject: Sun's XML Classes
Message-ID: <773251A595CFD111B8F800A0C998C55102CFA3@ris3.robco-inc.com>

What do you mean by helper methods? You mean taking Jack's suggestion and
just writing a little method that is going to wrap the newline and post the
field value all in one fell swoop? That does look good; I mainly wanted to
see what seasoned vets of this stuff were doing before I started rewriting.

Thanks,

R

-----Original Message-----
From: David Brownell [mailto:db@Eng.Sun.COM]
Sent: Monday, November 30, 1998 1:00 PM
To: Rob Williams
Cc: xml-dev@ic.ac.uk
Subject: Re: Sun's XML Classes


Rob Williams wrote:
> 
> I downloaded the Early Access of the Sun classes and they work ok, so far
> for what I've wanted to do with them. My question is, has anyone else
found
> that you end up writing a lot of ugly code to get simple things done?

That's basically what you get from using the W3C APIs directly.  Some of
what you're doing is more or less pretty-printing ... which the next
version will do for you automatically.

Also, as noted, helper methods are not only Your Good Friends but are
generally good style anyway!

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


From db at Eng.Sun.COM  Mon Nov 30 22:46:22 1998
From: db at Eng.Sun.COM (David Brownell)
Date: Mon Jun  7 17:06:49 2004
Subject: Why XML data typing is hard
References: <006501be1c6a$98e52de0$7008e391@bra01wmhkay.bra01.icl.co.uk> <13922.44021.68599.496798@localhost.localdomain> <f5b3e71oycq.fsf@cogsci.ed.ac.uk> <u90gtavea.fsf@delivery.ansa.co.uk>
Message-ID: <36631EDE.D152C6E7@eng.sun.com>

Toby Speight wrote:
> 
> Henry> Henry S. Thompson <URL:mailto:ht@cogsci.ed.ac.uk>
>  
> Henry> In other words, if there are (natural) language/culture dependent
> Henry> aspects to our documents, then if we are good citizens we should
> Henry> use the xml:lang attribute to signal this.

A good "if" ... related:  "if" the document is directly created or
consumed by humans, we should use some locale tagging.  ("xml:lang"
identifies language, not locale!)


> It looks attractive at first sight, but think of the burden you're
> placing on processors ... readers now
> need to know (enough about) *all* the locales from which they might
> receive data.

I'd contend that the "float" (or "r4") data _type_ doesn't have any
such localization issues.  IEEE floating point is a binary spec, and
nobody's proposed not assuming IEEE floating point.

Rather, this issue is an encoding issue.  By and large, having just
one (canonical) form is a lot easier for programs to deal with:  smaller
code, easier to debug, faster in normal cases, and so on.

But:  is this data being generated by/for programs, or people?  People
have different priorities than programs.

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


From ralph at fsc.fujitsu.com  Mon Nov 30 22:49:33 1998
From: ralph at fsc.fujitsu.com (Ralph Ferris)
Date: Mon Jun  7 17:06:49 2004
Subject: Hyperlink in XML
In-Reply-To: <5FAFB2A5D7B2D111ACEA0060972027CE186416@RADSYS_EXCH>
Message-ID: <3.0.5.32.19981130144805.00a53c00@pophost.fsc.fujitsu.com>

At 04:32 PM 11/30/98 -0500, Scott Roth wrote:
>Below is a sample of my XML data. I am curious to how I get the PanelListID
>data to show up as a hyperlink.  When I look at the file in the browswer it
>just has 5678, but no hyperlink.  Could somebody please help this
>newbie....?
>
>Thanks,
>Scott Roth
>
>
><FILE>
>      
>    <Workflow>FILE CLUSTER</Workflow>       
>     
>        
>    <FileID>1234</FileID>     
>    <PanelListID><a href="http://www.yahoo.com">5678</a></PanelListID> 
>    <Date>
>       <Day>13</Day>
>       <Year>1998</Year>
>       <Month>4</Month>
>    </Date>     
>   
>  </FILE> 

You need to declare the "a"-type element in your DTD:
 
<!-- simple link declaration -->
<!--                         -->
<!ELEMENT a  (#PCDATA)>
<!ATTLIST a
	xml:link CDATA #FIXED "simple"
	href     CDATA #REQUIRED
	inline   (true|false) true
	content-role  CDATA ""
	content-title CDATA ""
	title    CDATA ""
	role     CDATA ""
	actuate  (user|auto) user
	show     (new|replace|embed) replace
	behavior CDATA ""
>

You'll also need to define the formatting in your style sheet. In HyBrick,
since we're using DSSSL/Scheme as the style language, this looks like:

(element a
  (make link
	destination: (entity-address (attribute-string "href"))
	  (make score
    	type: 'after
    	color: red-color)))


Best regards,

Ralph E. Ferris
Fujitsu Software Corporation


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


From richard at cogsci.ed.ac.uk  Mon Nov 30 22:53:25 1998
From: richard at cogsci.ed.ac.uk (Richard Tobin)
Date: Mon Jun  7 17:06:49 2004
Subject: Non-validating parser behavior
In-Reply-To: Simon St.Laurent's message of Mon, 30 Nov 1998 16:48:35 -0500
Message-ID: <19034.199811302250@doyle.cogsci.ed.ac.uk>

> Are there any non-validating parsers that actually behave this way?

If non-validating mode, LT-XML trusts the standalone document
declaration, and does not fetch the external DTD part if standalone="yes".

-- 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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to 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 30 23:02:34 1998
From: ht at cogsci.ed.ac.uk (Henry S. Thompson)
Date: Mon Jun  7 17:06:49 2004
Subject: Why XML data typing is hard
In-Reply-To: "Liam R. E. Quin"'s message of "Mon, 30 Nov 1998 15:48:57 -0500 (EST)"
References: <Pine.BSI.3.96r.981130154456.8189C-100000@shell1.interlog.com>
Message-ID: <f5bzp98okcg.fsf@cogsci.ed.ac.uk>

"Liam R. E. Quin" <liamquin@interlog.com> writes:

> Henry S. Thompson writes:
> > if we add sensitivity to language to our lexical typing, I might write
> >
> > <balance xml:lang='fr'>4,50</balance>
> > <balance xml:lang='ar'>&#x0664;&#x066B;&#x0665;&#0660;</balance>
> [...]
> 
> david@megginson.com wrote:
> > It sounds quite plausible: it still places a burden of locale handling
> > on the processor or the application, but that's inevitable when we're
> > dealing with lexical constraints.  At least with this approach the
> > application will be able to fail gracefully:
> >
> 
> >   Warning: sample.xml line 18 column 12: Cannot validate constraint
> >            "float" for unsupported language "ar" (trying default
> >            locale en-CA).
> >
> 
> Where did the word "float" come from in that error message?
> 
> Is it part of an augmented DTD or Schema, or a stylesheet, or is it
> wired in to the application?

Sorry, I was too hasty in pruning the history of this thread:
somewhere back there David (I think) said (I paraphrase): "Consider a
'float' datatype declaration: it's not as straightforward as you might 
think", and then offered the 4.5/4,5 alternation as an example.

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


From dave at userland.com  Mon Nov 30 23:16:09 1998
From: dave at userland.com (Dave Winer)
Date: Mon Jun  7 17:06:50 2004
Subject: XML interface for groupware
In-Reply-To: <773251A595CFD111B8F800A0C998C55102CFA3@ris3.robco-inc.com>
Message-ID: <3.0.5.32.19981130151602.00ffdcf0@scripting.com>

We have a new web-based discussion board that has an XML interface. The
reading part of the interface works now, for example, you can visit this URL:

http://discuss.userland.com/msgReader.xml$598

To see the contents of message #598. Just change the number after the $ to
see a different message.

The writing interface will involve an XML-RPC handler, so it will be a
little more complicated, but not much more.

Let's keep diggin!

Dave

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