David Megginson wrote:
>
>   <foo>...</foo>
>     The attribute "bar" has the value "hack", and is not specified
>     (i.e., it is a defaulted value).
>
>   <foo bar="hack">...</foo>
>     The attribute "bar" has the value "hack", and is specified.

I don't think nsgmls (for example) makes this distinction and I don't
remember ever wishing it did. When do you need to know this?

As an author, I certainly don't think that my software is going to work
differently if I use the default or specify it. I would be quite
disconcerted if it did.

  Paul Prescod



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

Peter> Peter Murray-Rust <URL:mailto:peter@...>

> In article <3.0.1.16.19971218152122.29672990@...>,
> Peter wrote:

Peter> Is it the question of the return value of a non-existent
Peter> attribute.  IOW what does
Peter>
Peter> <!ATTLIST FOO PLUGH CDATA #IMPLIED>
Peter>
Peter> <FOO BAR="baz" XYZZY="" BLORT="six      spaces"/>
Peter>
Peter> return for
Peter> String s = element.getAttval("PLUGH");// could be "", or null

David has answered the original question (what is isSpecified() for in the
Java simple API?), but I thought I'd mention that DSSSL's attribute-string
function returns #f for PLUGH; the Java equivalent of this is of course,
null.  I think this is the Right Thing to do; it's sometimes important to
tell the difference between <Fu bargh=""/> and <Fu/>.

The first case is often used to mean a known, empty value; the second
to mean "not known" or "not applicable".

Concrete example: I'm a rock climber, and I keep a record of all my
climbing in XML format.  Climbs are defined as

climbs.dtd>   <!ELEMENT climb (#PCDATA)>
climbs.dtd>   <!ATTLIST climb
climbs.dtd>      grade CDATA ""
climbs.dtd>      stars CDATA #IMPLIED
climbs.dtd>      style (l|2|al|s|tr|mt) #IMPLIED
climbs.dtd>      with CDATA #IMPLIED
climbs.dtd>      >

Note the "stars" attribute, which is used for a climb's star rating
(an indication of quality).  An instance looks like

climbs.xml>  <climb grade="VD" stars="" style="2"
climbs.xml>   with="&p-hkm;">Difficult Crack</climb>

Here, the lack of stars is explicit - it's not a high-quality climb.
Whereas

climbs.xml> <climb grade="D" with="&p-ejk;, &p-dmj;"
climbs.xml>  style="l">King's Chimney</climb>

is a climb in a part of Britain where the star system isn't used, and
so I omitted the attribute - even though it probably deserves a star
or two.

I would not want these two values confused!

--

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

Since some of us may have time to relax, and since the following is *very*
close to what we are doing with the API, I have forwarded something I have
just received. [There was no useful metadata with the message.]

If anyone feels like translating the spirit into SGML/XML that could be
appropriate at this time of year in some countries.

[... header clipped ...]

-----------------------------------------------------------
Task is to write a program that prints "Hello World" on the
screen...make sure you see the last few attempts (Dilbert).

High School/Jr.High
==================

10 PRINT "HELLO WORLD"
20 END

First year in College
====================
program Hello(input, output)
begin
writeln('Hello World')
end.

Senior year in College
=====================
(defun hello
(print
(cons 'Hello (list 'World))))

New professional
===============
#include <stdio.h>

void main(void)
{
char *message[] = {"Hello ", "World"};
int i;

for(i = 0; i < 2; ++i)
printf("%s", message[i]);
printf("\n");
}

Seasoned professional
====================
#include <iostream.h>
#include <string.h>

class string
{
private:
int size;
char *ptr;

public:
string() : size(0), ptr(new char('\0')) {}

string(const string &s) : size(s.size)
{
ptr = new char[size + 1];
strcpy(ptr, s.ptr);
}

~string()
{
delete [] ptr;
}

friend ostream &operator <<(ostream &, const string &);

string &operator=(const char *);
};

ostream &operator<<(ostream &stream, const string &s)
{
return(stream << s.ptr);
}

string &string::operator=(const char *chrs)
{
if (this != &chrs)
{
delete [] ptr;
size = strlen(chrs);
ptr = new char[size + 1];
strcpy(ptr, chrs);
}
return(*this);
}

int main()
{
string str;

str = "Hello World";
cout << str << endl;

return(0);
}

Master Programmer :-))
================
[
uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820)
]

library LHello
{
// bring in the master library
importlib("actimp.tlb");
importlib("actexp.tlb");

// bring in my interfaces
#include "pshlo.idl"

[
uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820)
]
cotype THello
{
interface IHello;
interface IPersistFile;
};
};

[
exe,
uuid(2573F890-CFEE-101A-9A9F-00AA00342820)
]
module CHelloLib
{
// some code related header files
importheader(<windows.h>);
importheader(<ole2.h> );
importheader(<except.hxx>);
importheader("pshlo.h");
importheader("shlo.hxx");
importheader("mycls.hxx");

// needed typelibs
importlib("actimp.tlb");
importlib("actexp.tlb");
importlib("thlo.tlb");

[
uuid(2573F891-CFEE-101A-9A9F-00AA00342820),
aggregatable
]
coclass CHello
{
cotype THello;
};
};

#include "ipfix.hxx"

extern HANDLE hEvent;

class CHello : public CHelloBase
{
public:
IPFIX(CLSID_CHello);

CHello(IUnknown *pUnk);
~CHello();

HRESULT __stdcall PrintSz(LPWSTR pwszString);

private:
static int cObjRef;
};

#include <windows.h>
#include <ole2.h>
#include <stdio.h>
#include <stdlib.h>
#include "thlo.h"
#include "pshlo.h"
#include "shlo.hxx"
#include "mycls.hxx"

int CHello::cObjRef = 0;

CHello::CHello(IUnknown *pUnk) : CHelloBase(pUnk)
{
cObjRef++;
return;
}

HRESULT __stdcall CHello::PrintSz(LPWSTR pwszString)
{
printf("%ws\n", pwszString);
return(ResultFromScode(S_OK));
}

CHello::~CHello(void)
{
// when the object count goes to zero, stop the server
cObjRef--;
if( cObjRef == 0 )
PulseEvent(hEvent);

return;
}

#include <windows.h>
#include <ole2.h>
#include "pshlo.h"
#include "shlo.hxx"
#include "mycls.hxx"

HANDLE hEvent;

int _cdecl main( int argc, char * argv[])
{
ULONG ulRef;
DWORD dwRegistration;
CHelloCF *pCF = new CHelloCF();

hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);

// Initialize the OLE libraries
CoInitializeEx(NULL, COINIT_MULTITHREADED);
CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER,
REGCLS_MULTIPLEUSE, &dwRegistration);

// wait on an event to stop
WaitForSingleObject(hEvent, INFINITE);

// revoke and release the class object
CoRevokeClassObject(dwRegistration);
ulRef = pCF-Release();

// Tell OLE we are going away.
CoUninitialize();

return(0);
}

extern CLSID CLSID_CHello;
extern UUID LIBID_CHelloLib;

CLSID CLSID_CHello = { /* 2573F891-CFEE-101A-9A9F-00AA00342820 */
0x2573F891,
0xCFEE,
0x101A,
{ 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
};

UUID LIBID_CHelloLib = { /* 2573F890-CFEE-101A-9A9F-00AA00342820 */
0x2573F890,
0xCFEE,
0x101A,
{ 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
};

#include <windows.h>
#include <ole2.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include "pshlo.h"
#include "shlo.hxx"
#include "clsid.h"

int _cdecl main( int argc, char * argv[])
{
HRESULT hRslt;
IHello *pHello;
ULONG ulCnt;
IMoniker * pmk;
WCHAR wcsT[_MAX_PATH];
WCHAR wcsPath[2 * _MAX_PATH];

// get object path
wcsPath[0] = '\0';
wcsT[0] = '\0';
if( argc 1) {
mbstowcs(wcsPath, argv[1], strlen(argv[1]) + 1);
wcsupr(wcsPath);
}
else {
fprintf(stderr, "Object path must be specified\n");
return(1);
}

// get print string
if(argc 2)
mbstowcs(wcsT, argv[2], strlen(argv[2]) + 1);
else
wcscpy(wcsT, L"Hello World");

printf("Linking to object %ws\n", wcsPath);
printf("Text String %ws\n", wcsT);

// Initialize the OLE libraries
hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);
if(SUCCEEDED(hRslt)) {
hRslt = CreateFileMoniker(wcsPath, &pmk);
if(SUCCEEDED(hRslt)
hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello);
if(SUCCEEDED(hRslt)) {
// print a string out
pHello- PrintSz(wcsT);

Sleep(2000);
ulCnt = pHello- Release();
}
else
printf("Failure to connect, status: %lx", hRslt);
// Tell OLE we are going away.
CoUninitialize();
}

return(0);
}

Apprentice Hacker
==================
#!/usr/local/bin/perl
$msg="Hello, world.\n";
if ($#ARGV = 0) {
while(defined($arg=shift(@ARGV))) {
$outfilename = $arg;
open(FILE, " " . $outfilename) || die "Can't write $arg: $!\n";
print (FILE $msg);
close(FILE) || die "Can't close $arg: $!\n";
}
} else {
print ($msg);
}
1;

Experienced Hacker
==================
#include <stdio.h>
#define S "Hello, World\n"
main(){exit(printf(S) == strlen(S) ? 0 : 1);}

Seasoned Hacker
==================
% cc -o a.out ~/src/misc/hw/hw.c
% a.out

Guru Hacker
==================
% cat
Hello, world.
^^D

New Manager
==================
10 PRINT "HELLO WORLD"
20 END

Middle Manager
==================
mail -s "Hello, world." bob@b12
Bob, could you please write me a program that prints "Hello,
world."?
I need it by tomorrow.
^^D

Senior Manager
==================
% zmail jim
I need a "Hello, world." program by this afternoon.

Chief Executive
==================
% letter
letter: Command not found.
% mail
To: ^^X ^^F ^^C
% help mail
help: Command not found.
% damn!
!: Event unrecognized
% logout

begin:          vcard
fn:             Tim Preston
n:              Preston;Tim
org:            MDIS
adr;dom:        ;;Boundary Way;Hemel Hempstead;Herts;HP2 7HU;
email;internet: tpreston@...
title:          Principal Consultant
tel;work:       +44 1442 272084
tel;fax:        +44 1442 272777
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

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

At 04:15 AM 15/09/97 -0400, Tyler Baker wrote:
>I am not sure if this is at all relevant to this discussion, but I got some
info
>via email from the JDC newsletter that gives an interesting tip on how to
>efficiently build tree structures without sucking up too much RAM.

Lark does this now; amazing how Java, which "doesn't have pointers because
they're error-prone", does have something that smells just like (void *)...
in fact, one of the problems that bedevilled programmers for a generation
is that lots of useful C programs were written on VAXes, where a pointer
to everything was always the same size, then that wasn't true any more
on 16-bit DOS boxes; looks like from that point of view, Java is back
to the good old days of the VAX. -T.

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

Peter Murray-Rust writes:

  > >- an isSpecified flag for attributes
  >
  > Not quite clear what this is. I assume it is NOT the value of the Default
  > in the ATTLIST (i.e. "#IMPLIED").

DTD:

   <!ATTLIST foo
     bar CDATA "hack">

Document instance:

   <foo>...</foo>
     The attribute "bar" has the value "hack", and is not specified
     (i.e., it is a defaulted value).

   <foo bar="hack">...</foo>
     The attribute "bar" has the value "hack", and is specified.

   <foo bar="hello">...</foo>
     The attribute "bar" has the value "hello", and is specified.


All the best,


David

--
David Megginson                 ak117@...
Microstar Software Ltd.         dmeggins@...
       http://home.sprynet.com/sprynet/dmeggins/

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

At 07:32 18/12/97 -0500, David Megginson wrote:
>I think that the time has come to deal with a question that we have
>postponed so far: the goal of a simple XML event-driven interface.

Good thinking.  One of the really great aspects of XML was/is the 10 goals.

>Right now, there are two completely different ideas:
>
>1. The interface will provide standardised low-level, pre-DOM
>   functionality for parsers to implement, for programmers who do not
>   want to incur the overhead of using the DOM; perhaps a DOM tree
>   could be built using only these interfaces.

Yes. This is needed. It will be needed after the DOM is finalised. (It
might then be built on top of the DOM - I don't know). It is needed now (==
Jan 12).


>
>2. The interface will provide standardised high-level, post-DOM
>   functionality for parsers to implement, for programmers who do not
>   want to take the time to learn the XML concepts in the DOM; perhaps
>   the events could be generated from a DOM tree.

I understand and agree with the concept. I am not qualified to comment on
whether it is needed or is different from the API to the DOM.

>
>These two are actually quite incompatible: the first is an attempt to
>create a less abstract user model, while the second is an attempt to
>create a more abstract user model.  It's only a (happy) co-incidence
>that we have managed a broad agreement so far.

Yup. In my limited vision it is *possible* that (1) might be a subset of
(2), but not necessarily.
>
>
>LOW-LEVEL INTERFACE
>-------------------
>
>If we decided on (1), then I would consider making the interface the
>core interface for lfred, and I would probably want to expand it
>slightly to include enough functionality to build a basic level-1 DOM
>tree, by adding some or all of the following information:
>
>- an event for the doctype declaration

Essential IMO

>- an isSpecified flag for attributes

Not quite clear what this is. I assume it is NOT the value of the Default
in the ATTLIST (i.e. "#IMPLIED"). BUT this concept is required in some XLL
applications.

Is it the question of the return value of a non-existent attribute. IOW
what does
<!ATTLIST FOO PLUGH CDATA #IMPLIED>

<FOO BAR="baz" XYZZY="" BLORT="six      spaces"/>

return for
String s = element.getAttval("BAR");  // answer: "baz"
String s = element.getAttval("BLORT");// answer "six      spaces"
String s = element.getAttval("XYZZY");// answer ""
String s = element.getAttval("PLUGH");// could be "", or null
String s = element.getAttval("Y2");// could be "", or null

This is an area where I think we MUST spell out in graphic detail what is
returned. If nothing else, this is a prime reason for this API. I have got
this hopelessly muddled throughout JUMBO simply because there was no API. I
didn't want to hardcode in anything until the semantics of all this was
clear. At present JUMBO does not distinguish between a null String and "".
If this is going to be important (and I suspect it might) we need to know
NOW. It will be almost impossible to reprogram an application that gets it
"wrong".

Note for newcomers. If I add the declaration:

<!ATTLIST FOO BLORT NMTOKENS #IMPLIED>

and wave it over the document, the value of BLORT changes to

"six spaces"

This is always good for a laugh at XML parties, and you can probably make
money out of carefully placed bets.

>- ignorable whitespace (lfred should return this anyway)
>- comments (yech -- _WHY_ is that in the DOM???)
>
>This interface could use only JDK 1.0.2 features, since I have no
>intention of making lfred incompatible with existing browsers.

Agreed.

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

Michael Kay <M.H.Kay@...> wrote:
> (What I haven't really worked out yet, and would appreciate advice
> on, is how to turn the XML objects into a set of genealogical
> objects, with methods like getFather(), getMother(), getSpouses(). Do
> I need to build a separate tree with the data organised differently,
> or should I write methods/functions that operate on the nodes in
> the XML tree? I guess the chemists must have similar problems.)

I would strongly suggest first designing the genealogical object model
from the GEDCOM definitions (and other sources) without considering XML
or DOM at all.  You need to first get a good model of the information you
want to represent in a computer (usually called a DomainModel) before
considering technological/application constraints on it.  After you have
the model you can consider how that information could be best constructed
from an XML/GEDCOM encoding.
     The GEDCOM spec has a very specific model behind it, so you can
decide whether to use that model, a subset of it, or some improvement to
it.  There is a lot of stuff in there so it may take a while to get a
good DomainModel out of it and then implement that model in Java.  After
that, the XML should be very easy.
     Last time I checked (maybe a year or two ago), nobody had a
publically available GEDCOM object model or implementation in Java, but
maybe that has changed.  I spent several days starting the process of
building a model but got called off to other tasks [not sure where my
notes are].

If you have not already, you may want to look at Martin Fowler's Analysis
Patterns book or any of the three Amigos' books (Booch, Rumbaugh,
Jacobson).  Full references for these books are at:
     http://www.chimu.com/projects/mondo/links.html

--Mark
mark.fussell@...



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

At 06:14 18/12/97 -0800, Mark L. Fussell wrote:

[...]

>The current release is based on Aelfred but it was slightly modified to
>support InputStreams and so is included under a different package name.
>I will migrate mindo/MONDO to support the standard Java XML API when it
>is finalized.

Great. This is getting very close to David's 3+3 :-)

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

At 11:35 18/12/97 -0000, Michael Kay wrote:
>I like the way this discussion is going. I don't want to be on anyone's
>critical path, but I'll be trying out these interfaces (as an "application
>writer") if I can find the time.

This is really great Michael.

My vision of (at least one role of) the interface is precisely what you
describe. An intelligent, but ignorant Java/XML application programmer.
<QUOTE>
<BOOK PAGE="36" PUBLSHER="IOP" DATE="1973">A Random Walk in Science</BOOK>
<SCIENTIST NAME="Luria" SUBJECT="Biology" STATUS="Great">
I don't know what to assume...
</SCIENTIST>
<SCIENTIST NAME="Szilard" SUBJECT="Physics" STATUS="Great">
You may assume  infinite ignorance and unlimited intelligence
</SCIENTIST>
</QUOTE>

>I've written a very simple application using AElfred: a converter from an
>XML-based encoding of genealogical data back to the "standard"
>GEDCOM encoding.

This counts :-)

(The converter the other way was in Visual Basic,
>I will probably rewrite it in Java now I'm getting the hang of it.) It is
>beautifully concise, just 17 lines of code apart from the boilerplate
>which was copied straight from one of the AElfred sample apps,
>and will be even simpler with the proposed revisions to the
>interface.

This is exactly what we are after. The idea that we can develop an
application in a few lines is one of the beauties of XML. After all, we are
likely to get a lot more converts if they can write their app in half a
page. The boilerplate lends itself to GUI tools (e.g. presenting the
programmer with a dozen boxes to fill in for doEntity, etc.)

>
>To do anything more interesting with the data (i.e. anything that is not
>a single-pass operation) I need a tree representation. Yes, I don't
>want to build my own. The DOM seems to be the right solution for
>this. The idea of having a choice of parsers with the same event
>interface, and a choice of tree-builders that build the same DOM
>interface using any of the parsers, is very appealing.

Absolutely. JUMBO is essentially a tree-based tool and I expect it to
either implement the DOM or to simply hand over large chunk of current code
to better written stuff for tree management.

As you've probably seen, the Java SwingSet has a Tree tool, which comes
with an example. The major time taking is simply to find one's way around
the documentation.  I would have liked to use it for JUMBO and hacked a
simple example, but I need quite a lot of functionality for each displayed
node and I haven't yet found out how to do that (basically I need a
miniPanel for each node).
>
>(What I haven't really worked out yet, and would appreciate advice
>on, is how to turn the XML objects into a set of genealogical
>objects, with methods like getFather(), getMother(), getSpouses(). Do
>I need to build a separate tree with the data organised differently,
>or should I write methods/functions that operate on the nodes in
>the XML tree? I guess the chemists must have similar problems.)

I nearly replied to your earlier posting, but was too busy.

Any pure tree is extremely easy to represent in XML. So, if you simply want
to trace an ancestor tree (i.e. two parents, 4 grand parents, etc.) this is
trivial. If some happen to be identical you can use entities to normalise
the data or hyperlinks. E.g. your father's father's father could be your
mother's mother's father in most countries (cousin marriage). I can display
an animal taxonomy using nothing more than XML and standard JUMBO.

The difficulty comes when the graph has cycles. I am not an expert
genealogist, but most 'family trees' seem to me to be Directed Acyclic
Graphs (DAGs) where the arcs are isParentOf(); and is directional.  DAGs
are common in areas like multiple inheritance graphs (C++), multiple
ontological views, etc. I would hope that some standard ways of
representing DAGs might come out of XML and that there would be standard
viewing tools.

Note that the use of ID/IDREF may introduce additional complexity.
Personally I am not clear on the value of IDREF over XLL - it's not trivial
to support in a browser and I doubt that JUMBO will do it.

If we include marriage or other descriptions of human liaison we have a
different type of link. This results in a complex structure, which I would
use XLL to represent.  I'd value views on this, because we shall be
encountering XLL on this list from time to time :-)

One approach is to regard all nodes as disjoint, and to create every
relationship in a separate database. A fictitious family might look like:

<!ATTLIST RELATIONSHIP xml:link CDATA #FIXED "EXTENDED">
<!ATTLIST LOCATOR xml:link CDATA #FIXED "LOCATOR">

<LIST ID="people">
<PERSON ID="liz">Elizabeth</PERSON>
<PERSON ID="phil">Philip</PERSON>
<PERSON ID="chas">Charles</PERSON>
<PERSON ID="di" STATUS="deceased">Diana</PERSON>
<PERSON ID="cpb">Camilla</PERSON>
</LIST>

<LIST id="relationships">
<RELATIONSHIP ID="couple1>
<LOCATOR HREF="#ID(liz)" ROLE="wife">
<LOCATOR HREF="#ID(phil)" ROLE="hubby">
</RELATIONSHIP>
<RELATIONSHIP>
<LOCATOR HREF="#ID(chas)" ROLE="wife">
<LOCATOR HREF="#ID(di)" ROLE="hubby">
</RELATIONSHIP>
<RELATIONSHIP>
<LOCATOR HREF="#ID(chas)" ROLE="son">
<LOCATOR HREF="#ID(couple1)" ROLE="parents">
</RELATIONSHIP>
<RELATIONSHIP>
<LOCATOR HREF="#ID(chas)" ROLE="lover" BEHAVIOR="clandestine">
<LOCATOR HREF="#ID(cpb)" ROLE="lover">
</RELATIONSHIP>
</LIST>

To represent this structure prettily, and to navigate it usefully, is
almost certainly application-dependent. There are some nice graph layout
tools but they cannot render every application in a meaningful manner.
(Some might even be molecules :-)
>
>The other thing I need, which has not really been fully addressed,
>is access to the DTD. (Not for this application, which I am doing
>just as a learning exercise, but for my real job.) I think we need
>some kind of extension to the DOM to provide this.

I await other comments, but my expectations is that the DOM will actively
deal with this. Experts, please?

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

I released a version of mindo-j and an example DOM ObjectBuilder to:
    http://www.chimu.com/projects/mondo/release/

mindo-j is a minimal subset of MONDO suitable for accomplishing some
particular tasks.  The version above is focused on supporting DOM
document building,  but it can easily expand into much more functionality
and has a more general perspective than might be expected.  The example
includes a version of the DOM interfaces and a skeleton implementation.
This is very preliminary for the DOM code, but I am about to fly off for
the holidays so I thought it would be good to release it before then.

The current release is based on Aelfred but it was slightly modified to
support InputStreams and so is included under a different package name.
I will migrate mindo/MONDO to support the standard Java XML API when it
is finalized.

--Mark
mark.fussell@...

   i   ChiMu Corporation      Architectures for Information
  h M   info@...         Object-Oriented Information Systems
C   u    www.chimu.com         Architecture, Frameworks, and Mentoring

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

I think that the time has come to deal with a question that we have
postponed so far: the goal of a simple XML event-driven interface.
Right now, there are two completely different ideas:

1. The interface will provide standardised low-level, pre-DOM
    functionality for parsers to implement, for programmers who do not
    want to incur the overhead of using the DOM; perhaps a DOM tree
    could be built using only these interfaces.

2. The interface will provide standardised high-level, post-DOM
    functionality for parsers to implement, for programmers who do not
    want to take the time to learn the XML concepts in the DOM; perhaps
    the events could be generated from a DOM tree.

These two are actually quite incompatible: the first is an attempt to
create a less abstract user model, while the second is an attempt to
create a more abstract user model.  It's only a (happy) co-incidence
that we have managed a broad agreement so far.


LOW-LEVEL INTERFACE
-------------------

If we decided on (1), then I would consider making the interface the
core interface for Ælfred, and I would probably want to expand it
slightly to include enough functionality to build a basic level-1 DOM
tree, by adding some or all of the following information:

- an event for the doctype declaration
- an isSpecified flag for attributes
- ignorable whitespace (Ælfred should return this anyway)
- comments (yech -- _WHY_ is that in the DOM???)

This interface could use only JDK 1.0.2 features, since I have no
intention of making Ælfred incompatible with existing browsers.


HIGH-LEVEL INTERFACE
--------------------

If we decided on (2), then I would simply produce an optional add-on
for Ælfred, outside of its core interfaces (and probably in a separate
package).  I would probably make a pass-through class implementing
(the new) XmlProcessor instead of having Ælfred implement it directly,
so that the core Ælfred could still consist of only two class files.

In this case, the simple interface would be slightly less efficient,
and would include only very minimal functionality (as Tim suggests);
for anything more, you would have to use each parser's native
interface.  You could not build a DOM tree using this interface.

The question would remain open whether the simple interface could use
JDK 1.1 or JDK 1.2 features.


All the best,


David

--
David Megginson                 ak117@...
Microstar Software Ltd.         dmeggins@...
       http://home.sprynet.com/sprynet/dmeggins/

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

I like the way this discussion is going. I don't want to be on anyone's
critical path, but I'll be trying out these interfaces (as an "application
writer") if I can find the time.

I've written a very simple application using AElfred: a converter from an
XML-based encoding of genealogical data back to the "standard"
GEDCOM encoding. (The converter the other way was in Visual Basic,
I will probably rewrite it in Java now I'm getting the hang of it.) It is
beautifully concise, just 17 lines of code apart from the boilerplate
which was copied straight from one of the AElfred sample apps,
and will be even simpler with the proposed revisions to the
interface.

To do anything more interesting with the data (i.e. anything that is not
a single-pass operation) I need a tree representation. Yes, I don't
want to build my own. The DOM seems to be the right solution for
this. The idea of having a choice of parsers with the same event
interface, and a choice of tree-builders that build the same DOM
interface using any of the parsers, is very appealing.

(What I haven't really worked out yet, and would appreciate advice
on, is how to turn the XML objects into a set of genealogical
objects, with methods like getFather(), getMother(), getSpouses(). Do
I need to build a separate tree with the data organised differently,
or should I write methods/functions that operate on the nodes in
the XML tree? I guess the chemists must have similar problems.)

The other thing I need, which has not really been fully addressed,
is access to the DTD. (Not for this application, which I am doing
just as a learning exercise, but for my real job.) I think we need
some kind of extension to the DOM to provide this.

Regards and thanks for all the good work,
Mike Kay, ICL


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

At 04:15 15/09/97 -0400, Tyler Baker wrote:
[...]
>
>I am not sure if this is at all relevant to this discussion, but I got
some info

Well *I* found it extremely valuable :-). This is exactly the sort of thing
that novices will find a variety of ways of tackling. If your suggestions
gets support from those who know more than me, it may be worth considering
for the API.

FWIW I think that the presentation of Trees in the API is the area where
guidance is most valuable. If affects a lot of the downstream part of the
application. Moreover, if people return Objects from a Tree, their nature
has to be very carefully agreed. An Element or a PI is much more obvious by
comparison.

[...]
>In the parser application, using Object to represent both data types is not
>good enough because it still takes up too much memory.  So a further change
>has been implemented.  After doing some research, it was found that the
>child array consisted of a single Node element about 95 percent of the

Is this figure just for one application, or is it likely to have a
Ziff-like distribution (i.e. "most" XML applications will have only a
single non-terminal child at "most" of the nodes).

>time.  So it's possible to represent one-child cases directly using an
>Object reference to the child node, rather than a reference to a one-long
>array of child nodes.

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

At 03:35 18/12/97 -0500, Paul Prescod wrote:
>David Megginson wrote:
>>
[...]
Thanks Paul,

>> I
>> thought that it made sense to use them directly instead of using a lot
>> of Url.toString() and new URL(String) calls
>
>I think that all we are doing is shifting the "new URL(String)" calls
>from the processor to the application.

I think this is right - the "application" is going to have to do a lot of
additional testing for semantic validity. XLL is full of this problem. So I
think it will be very valuable to have *generic* modules that can be used
for this sort of thing. I see some of these as coming in a post-parser
(i.e. post-processor) and pre-application area. For example, it's
reasonable that an application shouldn't get passed:

<A XML-LINK="SIMPLE" HREF="htpp://www.some.where/myfile.xml" SHOW="Embed"
ACTUATE="New" behaviour="DISPLAY">My XML file</A>

This is a WF element, but contains a number of semantic errors (at least if
the application wishes to validate it against the XLL spec :-).
java.net.URL would catch one of them :-)

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

At 18:50 17/12/97 -0800, Russell East wrote:
>
>Yes!  I would like to be able to store one or more DTDs as
>resources within a JAR file.  Within a <!doctype ... SYSTEM "URL">
>I'd like to be able to refer to that DTD, rather than, refering
>to some server-side DTD.  But, I don't think we can do this now, because,

I think this is a tremendously important subject, Russell - thanks. One of
the exciting aspects of SGML/XML over the WWW is that it makes it possible
to distribute a whole environment. Like you I would want to be able to
"cache" some or all of these resources "client-side". One obvious reason is
slow lines, another is that people are often not connected to the WWW. For
example JUMBO - when used for molecular, statistical and other non-core XML
operations can be over 500Kb in classes.

>
>It would be good to be able to specify one of these URLs in SYSTEM,
>and have it work in all cases - not just appletviewer.

Personally I have enormous trouble with URLs under Java. There are the
following orthogonal problems:
	 - file: versus http:
	 - different syntaxes for files ('/' versus '\')
	 - different compilers (jvc vs javac)
	 - different JVMs (appletviewer, java, jview, NS (+versions), MS
(+versions), hotjava).
	 - different platforms (UNIces, Mac, Windows).

Altogether there are at least 20 actual variants.

For example, I contributed a JUMBO snapshot for Henry's latest CDROM on
chemical publishing [1]. Henry already has to test his CDROM for operation
with HTML and JavaScript (sorry ECMAScript). The CDROM has to run anywhere
and for people who have no knowledge of:
	 HTML
	 JavaScript
	 Who made the machine that they are viewing the CDROM on.
Adding:
	 Java
	 XML
is yet another dimension.

The ability to publish packaged systems under Java/XML is tremendously
exciting. I've done this in a limited way earlier this year and it seemed
to work. Henry's CDROM is going out with an issue of a paper Journal from
the Royal Soc of Chemistry but I don't expect a lot of feedback about JUMBO
- I suspect that most people won't get that far through the distribution
(the main rationale is *content* - organomettallic chemistry.)

A bizarre problem has just arisen. Please help me :-). The JUMBO snapshot
is arranged to run under a browser as well as a standalone interpreter. So
I have packaged it as this directory structure (not horizontal as hypermail
won't render it :-(

demos
	 mol.xml
	 mol.html
	 <ancillary JUMBO files>
	 jumbo
		 sgml
			 SGMLTree.class
		 cml
			 MOL.class
etc.

This runs OK with:
	 java jumbo.sgml.SGMLTree mol.xml
or
	 java jumbo.sgml.SGMLTree file:/C:/mydir/demos/mol.xml
or (I think)
	 java.jumbo.sgml.SGMLTree file:mol.xml
and even
	 java jumbo.sgml.SGMLTree mol.xml PARSER=AElfred

mol.html contains:
<APPLET CODE="jumbo.sgml.SGMLTree.class" WODTH=300 HEIGHT=300>
<PARAM NAME="commandline" VALUE="mol.xml PARSER=Lark">
</APPLET>

When mol.html was loaded this used to work fine, launching JUMBO and
reading the file. Henry tells me that it still works for him under Netscape
4.04. BUT on my own PC with NS4.02 it now throws a SecurityException when
it comes to read file:/C:/cdrom/demos/mol.xml saying it isn't allowed to
read a local file.
So it seems to be a PMR-environment-specific problem. Help would be really
appreciated. Are there any browsers switches, config files etc that I might
have corrupted? Or is everyone benefitting by a laxer implementation of
Applet Security?



[...]
>
>Do the XML parser developers have any suggestions on how to achieve this?

I don't think it's just for parser developers - anyone can play.

>
>Does it make sense to have a special API for the parser through which
>you can not only specify an xml document, but also a separate dtd ?

I think this is part of the namespace activity.  JUMBO implements
namespaces experimentally (all namespace stuff is experimental!) and it
involves a lot of subsidiary files (JUMBO has one for most ELEMENTs, schema
files  and much more). JUMBO can also use 3 parsers and will - by Jan 12
;-) be able to use 5. As we've seen, these parsers provide additional
features so that it makes sense to distribute them (authors permitting of
course) with the JUMBO distribution. It's also possible - as you suggest
that different DTDs (or, I suspect namespaces) might be distributed as
well. For example, it could make sense to have a variety of support files
for HTML4.0/XML. The reader could then choose between these at browse time.

This requires something with the functionality of a JAR file. I take the
concern that we shouldn't become Java-only, but I think the *experience*
with JAR files for early XML adopters will be essential. So - not for Jan
12 - some communal activity here on distribution, manifests, installation,
etc would be extraordinarily helpful to the success of XML. If we can
reliably distribute our XML applications without worrying about what's at
the other end it would be marvellous. It's a very different sort of task
from writing a parser :-)

	 P.
[1]
Some people may not know who Henry Rzepa is. Henry is the world's leading
exponent of the use of the Internet and related technologies for chemical
information and publishing. [He also does mainstream research in
computational chemistry.] He has run 3 major electronic conferences on
chemistry (content-driven) and published these with the Royal Society of
Chemistry through an E-lib project, CLIC. This project, including
Cambridge, Leeds and IC is committed to the use of SGML/XML as a publishing
tool. This explains some of his and my enthusiasm for seeing XML succeed.
Our primary concern is to see the link between author and reader as direct
as possible without information loss or corruption.


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

David Megginson wrote:
>
>  > And one last thing: if you use URL, then you have to do a new URL()
>  > which does (I think) at least some syntax checking... is this appropriate?
>  > Why not just pass it as a string? -Tim
>
> For starting Ælfred, I found using a string awkward, since I needed a
> base URL to resolve relative URLs (like file names).

XML attributes will probably have relative URLs in them and the XML
Application will have to know how to resolve them. Tim is right that
attributes are syntactically checked when they are created and can throw
an exception if there is a mistake. I would rather leave that up to the
application writer.

> Since XML
> mandates URIs anyway, and Java supports them pretty transparently,

XML mandates URIs, but Java supports URLs. I don't think that all Java
environments will allow new URL types to be installed. But if we are
just passing around strings then the application can recognize URNs and
Do The Right Thing.

> I
> thought that it made sense to use them directly instead of using a lot
> of Url.toString() and new URL(String) calls

I think that all we are doing is shifting the "new URL(String)" calls
from the processor to the application.

  Paul Prescod



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

Don Park wrote:

> >I didn't suggest XmlApplication should should store XmlProcessor in a
> >member variable.  I suggested that implementations of XmlApplication
> >could (if they needed to make callbacks to XmlProcessor) store
> >XmlProcessor in a member variable.
>
> OOPS.  Point taken.
>
> >I don't think it's appropriate to carry over patterns from GUI events
> >and apply them to XML events just because we happen to use the word
> >"event" to describe them both.  I believe performance is important for
> >XML processing, and an interface shouldn't impose an unnecessary
> >performance cost.
>
> >
> >The real merit of this interface is that it's simple; unless there's a
> >really compelling need for a feature, I think it should be left out.
>
> While David suggested that add/removeApplication methods allow
> implementation of XmlProcessors which support multiple XmlApplications, it
> is completely up to the implementations to support multiple XmlApplication
> or only one at a time.  As JavaBeans spec suggests,
> TooManyListenersException should be thrown if XmlProcessor supports only one
> XmlApplication for performance and simplicity sake.
>
> >> I do not think so.  Just as every Mac developer loved having RefCon to
> hang
> >> thing onto, I like userData.
> >
> >Could you explain a typical case where you need this?
> >
> >Are there any standard Java classes that do this?
>
> userData is a cheap way to associate extra info with the XmlProcessor.  For
> example, I can store the source URL in the userData.  There are other ways
> to have XmlProcessors provide the URL info (i.e. Java Activation Frame has
> URLDataSource for this) but they are fairly expensive and would
> unnecessarily taint the API with URL related stuff.  It should be possible
> to use XmlProcessor with a File and building URL out of File is not reliable
> in all platforms.
>
> Don
>

I am not sure if this is at all relevant to this discussion, but I got some info
via email from the JDC newsletter that gives an interesting tip on how to
efficiently build tree structures without sucking up too much RAM.  I figure,
that for building XML parsers the most efficient way of storing the parsed data
would be some help to the XML parser writers.  Anyways, here is the tip.



PERFORMANCE -- using Object to represent disparate types.  This tip is a
little tricky, but it recently came up in an actual application, and
illustrates how Java language features are used to efficiently represent a
large data structure.

The application is one where a very large tree structure, consuming
millions of bytes, is built up.  Some of the nodes in the tree reference
child nodes (non-terminals), while others are leaf nodes (terminals) and
have no children, but contain String information.  The application involves
parsing a large Java program and representing it internally via a tree.

One simple approach to this problem is to define a Node class such as the
following:

         public class Node {
                 private int type;
                 private Node child[];
                 private String info;
         }

If the node is a leaf node, then info is used.  Otherwise, child refers to
the children of the node, and child.length to the number of children.

This approach works pretty well, but uses a lot of memory.  Only one of
child and info are used at any one time, meaning that the other field is
wasted.  Child is an array, with attendant overhead, for example, in
storing the dimensions of the array for subscript checking.  For certain
large inputs, the parser program runs out of memory.

The first refinement of this approach is to collapse child and info:

         public class Node {
                 private int type;
                 private Object info;
         }

In this scheme, info can refer to either a String, for a leaf node, or to a
child node array.  Object is the root of the Java class hierarchy, so that
for example, the following:

         class A {}

implicitly means:

         class A extends Object {}

An instance of a subclass of Object, such as String, can be assigned to an
Object reference.  An array of Nodes can likewise be assigned to an Object.
The instanceof operator can be used to determine the actual type of an
Object reference.

In the parser application, using Object to represent both data types is not
good enough because it still takes up too much memory.  So a further change
has been implemented.  After doing some research, it was found that the
child array consisted of a single Node element about 95 percent of the
time.  So it's possible to represent one-child cases directly using an
Object reference to the child node, rather than a reference to a one-long
array of child nodes.

This representation is complicated, and it's useful to define a method for
encapsulating the abstraction as in the following example:

         public class Node {
                 private int type;
                 private Object info;

                 // constructors, other methods here ...

                 // gets the i-th child reference
                 public Node getChild(int i)
                 {
                         if (info instanceof String)
                                 return null;
                         else if (info instanceof Node && i == 0)
                                 return (Node)info;
                         else
                                 return ((Node[])info)[i];
                 }
         }

getChild returns the i-th child, or null for leaf nodes.  If there is
exactly one child, then info is of type Node, referencing that child.  If
there is more than one child, info is of type Node[], and a cast to Node[]
is done, followed by a retrieval and return of the child reference.

In the parser application, this change is enough to tip the scales, so that
the application would not run out of memory.  The internal representation
in this example is tricky, but it can be hidden via methods such as
getChild.  In general, it's wise to avoid tricky coding, but useful to know
how to do it when the need arises.

The example also illustrates the utility of using one Object reference to
represent several different data types.  In C/C++ similar techniques would
use void* pointers or unions.


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

Since JavaSoft is notoriously late updating its web pages, I thought some of
you might be interested to know that JDK 1.2 Public Beta is finally out at:

http://developer.javasoft.com/developer/earlyAccess/jdk12/

Please do not reply to this message cause I don't want to receive another
LISTRIVIA from Peter :-p

Don "JStud" Park
Master Consultant
donpark@...

<spam>
Come visit my XML Example Catalog at
http://www.quake.net/~donpark/xmlcat.html
</spam>



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

Antony Blakey wrote:
> .... What we need to do is ... provide the
> input stream from within the program ie. the entity is stored as a string, or
accessed
> through ClassLoader.getResourceAsStream()...

Yes!  I would like to be able to store one or more DTDs as
resources within a JAR file.  Within a <!doctype ... SYSTEM "URL">
I'd like to be able to refer to that DTD, rather than, refering
to some server-side DTD.  But, I don't think we can do this now, because,
we can't specify a URL for a JAR resource - well, we can't do it in a
platform independent manner anyway, because JavaSoft states, at
http://java.sun.com/products/jdk/1.1/docs/guide/misc/resources.html :

  "The method getResource() returns a URL for the resource.
   The URL (and its representation) is implementation-specific
   and may vary depending on the implementation details (it may
   also change between JDK1.1 and JDK1.1.1). Its protocol is
   (usually) specific to the ClassLoader loading the resource.
   If the resource does not exist, a null will be returned."

It's hard to test this, firstly Netscape doesn't yet seem to support
ClassLoader.getResource() and IE4 doesn't seem to support JARs as
containers for resources.  For instance, I have a sample applet which
is placed into a JAR along with a resource named test.dtd.  Within
JDK 1.1.4 appletviewer, getResource() returns the URL of this
resource as:    appletresource:/file:/D:/Ims/z//+/test.dtd
or : appletresource://gumnut/http://gumnut/ims/z//+/test.dtd
depending on whether I access the HTML thru my webserver or not.

It would be good to be able to specify one of these URLs in SYSTEM,
and have it work in all cases - not just appletviewer.

Do the XML parser developers have any suggestions on how to achieve this?

Does it make sense to have a special API for the parser through which
you can not only specify an xml document, but also a separate dtd ?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        Russell East                    mailto:reast@...
  _|_|  Programmer                      phn: +1 (909) 793 2853
  _|_|  ESRI, 380 New York St           fax: +1 (909) 307 3067
        Redlands CA 92373-8100          http://maps.esri.com/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

At 14:36 17/12/97 -0800, Don Park wrote:
[...]
>If Chris does not object or respond, I can step up and provide the
>implementation for MSXML by 12 January.  There is nothing in the license
>that prohibits me from implementing the simple API over MSXML.
>
Great - I would really love the have that. I assume that it is fairly
stable now (1.8?) and that the various queries on this list have been
resolved...

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

>I didn't suggest XmlApplication should should store XmlProcessor in a
>member variable.  I suggested that implementations of XmlApplication
>could (if they needed to make callbacks to XmlProcessor) store
>XmlProcessor in a member variable.


OOPS.  Point taken.

>I don't think it's appropriate to carry over patterns from GUI events
>and apply them to XML events just because we happen to use the word
>"event" to describe them both.  I believe performance is important for
>XML processing, and an interface shouldn't impose an unnecessary
>performance cost.

>
>The real merit of this interface is that it's simple; unless there's a
>really compelling need for a feature, I think it should be left out.

While David suggested that add/removeApplication methods allow
implementation of XmlProcessors which support multiple XmlApplications, it
is completely up to the implementations to support multiple XmlApplication
or only one at a time.  As JavaBeans spec suggests,
TooManyListenersException should be thrown if XmlProcessor supports only one
XmlApplication for performance and simplicity sake.

>> I do not think so.  Just as every Mac developer loved having RefCon to
hang
>> thing onto, I like userData.
>
>Could you explain a typical case where you need this?
>
>Are there any standard Java classes that do this?


userData is a cheap way to associate extra info with the XmlProcessor.  For
example, I can store the source URL in the userData.  There are other ways
to have XmlProcessors provide the URL info (i.e. Java Activation Frame has
URLDataSource for this) but they are fairly expensive and would
unnecessarily taint the API with URL related stuff.  It should be possible
to use XmlProcessor with a File and building URL out of File is not reliable
in all platforms.

Don



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

>In other words, we need at least one other parser writer on board
>besides Tim and me (a duopoly is almost as bad as a monopoly), and at
>least two other applet/application writers besides Peter.  If we don't
>have that agreement, and a working beta interface, by 12 January, I
>won't want to spend any more of my time on this issue (I have other
>projects that I'd like to pursue).


If Chris does not object or respond, I can step up and provide the
implementation for MSXML by 12 January.  There is nothing in the license
that prohibits me from implementing the simple API over MSXML.

As far as James' concern over having a simple DOM, I think one of us can
implement a XmlApplication that produces W3C DOM objects so programmers can
just deal with DOM.  Any takers?

Don



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

Andrea Anders wrote:

> I am a amateur in xml...

As are we all...

> I try to transform a SGML-DTD into XML (I use MSXML-parser). My questions are:
>
> 1) Neither SGML-inclusions nor -exclusions are allowed in XML!? How can I
> express this in XML?

Inclusions and (to a lesser extent) exclusions have never really been a great
idea in SGML because of the potential for them to behave incorrectly when
parsing
from somewhere other than the top level of the DTD. Depending on how widely
they've been used and how big your data set is, I'd be inclined to process all
of
your documents and generate a report of the ancestors elements of the
inclusions.
This will give you some perspective about how they've been used - you can then
make informed decisions about their handling and requirements. Exclusions can be
overcome by remodelling the content models, but this could be a substantial
amount of work if your DTD is large and/or complex.

That's the way I wouldn't do it. I would maintain the data as SGML and call it
XML as required. Does it need to be valid, or can it just be well formed? Be
careful about white-space around the inclusions and exclusions if you use this
approach - no matter how you slice it, they're bad news.


--
Regards

Marcus Carr                  email:  mrc@...
_______________________________________________________________
Allette Systems (Australia)  email:  info@...
Level 10, 91 York Street     www:    http://www.allette.com.au
Sydney 2000 NSW Australia    phone:  +61 2 9262 4777
                              fax:    +61 2 9262 4774
_______________________________________________________________


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

A few comments related to a few posts:

I. Multiplicity of Application - Processor relationship

The "one app, multiple processors argument" is not convincing in my opinion:
(a) I don't think this use of the simple API would be common, and (b) it is
trivial to implement a solution that does this outside the API. I feel the
same about the argument "one processor, multiple applications".

If we make the multiplicity of the relationship between XmlApplication and
XmlProcessor 1 to 1 we can eliminate the XmlProcessor arguments to
XmlApplication methods AND the get/set methods for user data in
XmlProcessor. Additionally, we won't need both addApplication() and
removeApplication().

I see the removal of at least three methods in XmlProcessor and the removal
of XmlProcessor as an argument to XmlApplication methods a substantial gain
for the simple API. Further, I'll get immense personal satisfaction from
seeing the handling of arbitrary user data removed from XMLProcessor.

II. Positional information

I'm somewhat surprised that parser writers claim it is difficult to extract
information about the positions of elements in an XML document. Can s.o.
explain why this is the case? In my work with markup languages I've always
represented the position of elements with a pair of (offset in data stream,
line number, column number) triplets. Providing this information will
certainly result in slightly lower performance, but the functionality it
enables for editing, good error reporting and validation is significant.

III. Exceptions

I am uncertain about the implications of exceptions leaving either the
XmlProcessor or the XmlApplication objects. In particular, I am wondering
what would happen if the XmlProcessor and XmlApplication are used as beans.
I know that in the COM/CORBA world this is very undesirable.

In general, I think it leads to a more complicated programming mechanism.
S.o. mentioned that stopping the parse is difficult with top-down parsers.
While this is true in principle, I there are some very simple mechanisms for
stopping a top-down parse. I'd be happy to discuss these with whoever is
interested.

IV. IDL

I did try a number of times to bring up the issue of a language independent
API with little success. I do see the benefit of something being done with
Java right now, so I'll just wait for the Java API to stabilize before
looking at ways to express it in IDL.

Regards,

Simeon Simeonov
Allaire


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

> I am a amateur in xml and hope anyone can help me.
>
> I try to transform a SGML-DTD into XML (I use MSXML-parser).
> My questions are:
>
> 1) Neither SGML-inclusions nor -exclusions are allowed in XML!? How can I
>    express this in XML?
>
>    my sgml-dtd:
>
>    <!ELEMENT LE - - ((a , b , c+) , d , e) +(f , g , h) >
>    <!ELEMENT m - - (o | (#PCDATA))+ >
>    <!ELEMENT c - - (l , (m | n)+) >
>    ...
>    <!ELEMENT e - - (i , (j , k)+) -(h)>

First, let's simplify your SGML DTD, which has too many brackets in
it:

<!ELEMENT LE - - (a , b , c+ , d , e)    +(f , g , h) >
<!ELEMENT m - - (o | #PCDATA)+ >
<!ELEMENT c - - (l , (m | n)+) >
...
<!ELEMENT e - - (i , (j , k)+)    -(h)>

Putting the PCDATA in the right place for XML, and removing the
minimization tokens, we get:

<!ELEMENT LE  (a , b , c+ , d , e)    +(f , g , h) >
<!ELEMENT m   ( #PCDATA|o)+ >
<!ELEMENT c    (l , (m | n)+) >
...
<!ELEMENT e    (i , (j , k)+)    -(h)>

So you want f, g and h to be accessible in a, b, c, d and e, but also
in l, m and n, but only f and g in i, j and k. Of course, you may not
want any of these directly in LE, c and/or e, though inclusions
automatically allow this. Only you can decide. Assuming that you do want them...

<!ELEMENT LE  ((f|g|h)*, a ,(f|g|h)*,  b ,(f|g|h)*, (c|f|g|h)+
,(f|g|h)*, d ,(f|g|h)*,  e(f|g|h)*)>
<!ELEMENT m   ( #PCDATA|o|f|g|h)+ >
<!ELEMENT c    ((f|g|h)*,l , (f|g|h)*, (m |n|f|g|h)+) >
...
<!ELEMENT e    ((f|g)*,i , (f|g)*, (j, (f|g)* , k (f|g)*)+)>

In one sense you are lucky in this example, because you do not have
the same element having different content depending on its context.
Suppose the following:

<!ELEMENT chapter - - (para*, section*) >
<!ELEMENT para - - (#PCDATA)>
<!ELEMENT section (para+) +(xref)>

Here, the para element may have an xref, but only if it apepars
inside a section element. To do this in XML requires the definition
of a new element, perhaps called sect_para

<!ELEMENT para - - (#PCDATA|xref)*>

Neil.





-----------------------------------------------
Neil Bradley - Author of The Concise SGML Companion.
neil@...
www.bradley.co.uk

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

At 14:03 17/12/97 -0500, David Megginson wrote:
[...]
>
> > >  public void
> > >    processingInstruction (XmlProcessor processor, String target,
String data);
>
>I disagree -- processing instructions are an essential part of a
>document (especially for architectural forms).
>

I'd tend to agree on keeping PIs in as well. Both Lark and lfred do them at
present. They are used in namespaces (which JUMBO is able to do something
with) and there are also other local uses.

	 It's going great :-)

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

Peter Murray-Rust wrote:
>
> The interface has to be simple enough for people like me to understand and
> to tell my friends what it's about. I would prefer to limit the Consumers,
> Factories and the rest to as few as possible.

An IDL interface implies no extra complication in the Java interface. It
merely describes the Java interface in terms that are more universal
than Java itself -- it is like a DTD for interfaces. So far nobody has
yet proposed anything that would make an IDL description impossible. All
I ask is that:

a) nobody do so later (e.g. require runtime lookup of Java class objects
or do something simiarly brain-dead) and

b) implementations in other languages be considered "successes" in terms
of the success/failure of this project.

I don't think that either of these constraints endanger the success of
the Java-specific part of the project or make the Java-specific part
more difficult.

  Paul Prescod


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

At 10:12 17/12/97 -0800, Mark L. Fussell wrote:
[... offer of MONDO on top of API...]

>
>On the application side (or meta-application), I will commit to having
>MONDO and mindo on the API within a couple days of when you release it.
>As a semi-application, this includes a DOM builder that I will be
>releasing early tomorrow.  Is this acceptable as an application?

sounds great to me :-) I'll leave the others to comment on the DOM stuff.

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

At 10:35 17/12/97 -0800, Tim Bray wrote:
>
>Oops; and I forgot the IMPORTANT one: I don't see any point in doing
>this if there isn't also an ultra-simple tree interface supporting
>only Element, Attribute, and Text classes.  Because this is what most
>people will use, especially given that a high proportion of XML
>transmissions will be small flattish documents; why should everyone
>have to build their own tree. -Tim

Yes - this is really important, because it fixes the terminology.  We also
know whether we have a Vector of children or some other model.

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

At 11:06 17/12/97 -0500, Paul Prescod wrote:
>David Megginson wrote:
>> 1) By Monday 12 January 1998, at least three Java parser writers have
>>    not agreed to support a specific set of common interfaces.
>
>What about a Python parser writer? We are, after all, on the brink of
>the 21st century. It would be really nice to stop the cycle of
>"crowning" one language the be-all and end-all of programming languages.
>
>Could we specify the interfaces in terms of IDL instead of Java (or
>perhaps agree to make an IDL version soon after the Java one)? The only
>extra work I see is that we must explicitly define the interfaces for
>URL and Dictionary so that other languages can implement Java-compatible
>versions.

Please can I very gently suggest that we stick precisely to what David has
suggested. It has the merit that we all understand it. [Strange as it may
seem I have never seen any Python or IDL, so it would make my job a lot
harder.]

The interface has to be simple enough for people like me to understand and
to tell my friends what it's about. I would prefer to limit the Consumers,
Factories and the rest to as few as possible.

On the main goals is to show that we can actually accomplish something
communally. That in itself will be a big achievement, because after that it
should get simpler.  We choose java because it's one of the main languages
of the WWW, it's free and the majority of the programs reported here are in
Java.

26 days and counting. In some countries some of the people will be on
holiday for some of the time. There are three more bodies to recruit. We
need people to hack code.

	 P.

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