From Jon.Bosak at eng.Sun.COM Sat Aug 2 07:08:47 1997
From: Jon.Bosak at eng.Sun.COM (Jon Bosak)
Date: Mon Jun 7 16:58:11 2004
Subject: XML Dev Day schedule
Message-ID: <199708020506.WAA20598@boethius.eng.sun.com>
A fine assortment of technical presentations is in store for
participants in XML Developers Day (Le Centre Sheraton Hotel,
Montreal, Thursday, August 21). In fact, the "day" has had to be
extended into the evening to accommodate a wealth of reports from
early implementors of the new Web technology. This is going to be a
can't-miss event for anyone hoping to play a significant role in the
coming revolution.
Registration for XML Developers Day can be made through the page for
the 4th International HyTime Conference:
http://www.gca.org/conf/hytime/hytime97.htm
Participants new to XML should note that in addition to the many
interesting presentations scheduled for the HyTime Conference (August
19-20), a tutorial on XML will be given on Monday, August 18 in the
same location.
Jon Bosak
Dev Day Chair
=========================================================
PRELIMINARY SCHEDULE: XML DEVELOPERS DAY, AUGUST 21, 1997
=========================================================
9:00-9:05 Jon Bosak, Sun Microsystems
Welcome
9:05-9:30 David Megginson, Microstar
Java Beans and Architectural Forms
9:30-10:00 Lloyd Harding, Information Automation Assembly
The Kona Proposal for Electronic Health Care Records
10:00-10:30 Henry Thompson, University of Edinburgh
A Motivation for the Schema Component of XML-Data
10:30-11:00 ------------------------------ BREAK
11:00-11:30 Daniel Rivers-Moore, RivCom
XML in the Delivery of Corporate Information
11:30-12:00 Patrick Gannon, CommerceNet
XML in Component-based Commerce
12:00-1:30 ------------------------------ LUNCH
1:30-2:00 John Tigue, Datachannel
XAPI-J in Theory and Practice
2:00-2:30 Jeffrey Olson, School of EECS, Washington State University
Conceptual Knowledge Markup Language, an XML Application
2:30-3:00 Henry Thompson, University of Edinburgh
The Win95/NT Version of LT XML
3:00-3:30 ------------------------------ BREAK
3:30-4:00 Paul Trevithick, Bitstream
Highly Designed Pages and Cross-Media Authoring with XML
4:00-4:30 Sarah Slocombe, Apropos Toy & Tool Development
A Java-based QuarkXpress-to-XML Converter
4:30-5:00 David Slocombe and Rajiv Thanawala, Tata Infotech
A Visual Recognition Approach to Legacy Document Conversion
5:00-5:30 ------------------------------ BREAK
5:30-6:00 Murray Maloney, Grif
XML Editing: Well-formed Documents, CSS, and Namespaces
6:00-6:30 Paul Grosso, ArborText
Some Ideas for XML Editing Interfaces
6:30-7:00 Jonathan Robie, POET Software
An XML Document Component Database
7:00-7:30 Jeff Eby, Chrystal Software
XML and a Generic Repository Architecture
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From neil at bradley.co.uk Sat Aug 2 10:38:48 1997
From: neil at bradley.co.uk (Neil Bradley)
Date: Mon Jun 7 16:58:11 2004
Subject: Specification Questions
Message-ID: <199708020838.JAA11135@andromeda.ndirect.co.uk>
Thanks for the feedback, it was very helpful. However, I STILL do not
understand the need for the brackets in the latter half of Mixed:
>
>
> > The second line of the rule for [50]Mixed is:
> >
> > | '(' S? %( '#PCDATA' ) S? ')'
> >
> > I cannot understand the purpose of the inner brackets in this part
> > of the rule.
>
> I believe it is to allow parameter entity replacement at that spot:
>
>
>
I understand the explanation, but the first half of the same rule is
as follows:
'(' S? %( %'#PCDATA' ( ..........
If %'#PCDATA' can appear here, why can't the second part of the
rule be similarly formulated:
| '(' S? % '#PCDATA' S? ')'
Am I wrong in thinking this would allow a content of " ( %xyz; ) "?
> > There is also little written about interpretation of line-ending
> > codes. Although the standard states that white space and
> > line-ending codes are ignored in element content, nothing is said
> > regarding the age old problem of line-ending codes in mixed
> > content.
>
> The spec makes no special provision for whitespace at the beginning
> and end of elements. I believe that this is intended to be one of
> its simplifications over "regular" SGML. This seeming
> incompatibility is mitigated by an an SGML TC which will allow XML
> to remain compatible with (post-TC) SGML.
>
> Paul Prescod
Is it up to the application to decide what to do with any leading line
ending code in these positions then?
I am pleased to be rid of the 'record' concept (using RS and RE)
defined for SGML, particularly as I have tended to use Mac and UNIX
systems which use a single character to end a line (albeit different
ones!). However, I still think there is too little information on the
effect of line ending codes in mixed content. Obviously the safe thing
to do is to make the content of all elements with a mixed content
model fit on a single line, as in:
This is a long paragraph.........................
But with large text blocks, created using text editors, people will
continue to use line ending codes to make it readable on-screen.
Normally, a break between words would be interpreted as a space when
the block is paginated:
This is a long paragraph that is broken over two
lines, with an implied space between 'two' and 'lines'.
Yet what happens when a comment or processing instruction
appears on its own line?
This is a long paragraph that is broken over two
lines, with an implied space between 'two' and 'lines'.
Is this interpreted as "two lines...", which reduces
to "two lines"?
Neil.
-----------------------------------------------
Neil Bradley - Author of The Concise SGML Companion.
neil@bradley.co.uk
www.bradley.co.uk
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From Peter at ursus.demon.co.uk Sat Aug 2 11:56:33 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:12 2004
Subject: Specification Questions
Message-ID: <9075@ursus.demon.co.uk>
In message <199708020838.JAA11135@andromeda.ndirect.co.uk> "Neil Bradley" writes:
[...]
[Paul Prescod]
> > The spec makes no special provision for whitespace at the beginning
> > and end of elements. I believe that this is intended to be one of
> > its simplifications over "regular" SGML. This seeming
> > incompatibility is mitigated by an an SGML TC which will allow XML
> > to remain compatible with (post-TC) SGML.
The spec is consistent over this, I think, and says that all characters that
are not markup should be passed to the application. This includes whitespace.
My personal view is that without some central guidance at least, the
XML treatment of whitespace will cause problems and incompatibility for
two groups of people:
- those who are familiar with SGML
- those who are not familiar with SGML.
The first group are accustomed to SGML parsers (primarily James Clark's)
carrying out consistent operations on whitespace. This includes:
- removing line-ends immediately after and before markup
- translating markup into a small number of platform-independent codes
(e.g. ' ' and '\n').
The second group will be familiar with HTML where all whitespace is normalised
according to various rules of varying consistency between useragents/browsers.
Apart from characters within
and related markup, all whitespace is
normalised to single spaces, which and line-ends are inserted according to
the user-agent software, not the document's content. Treatment of 'special'
characters (e.g. and other escaped characters or entities) is
probably inconsistent. However, in general, whitespace is not a current
concern of the second group.
***Both groups are in for a serious problem with XML unless there is some
central guidance. Otherwise we are at the mercy of any software implementor.
***
What whitespace characters can be passed to the application? Regardless of
what is done with it, is CR+LF treated in the same way as LF or CR alone
in a document?
If not, we shall appear to be in for variations according to what platforms
the document is created on. It will be no use telling people that this is
what the spec says - I had always assumed that one of the attractions of
SGML was that it removed platform-dependent documents. But reading
XML-lang [2] suggests that CR and CR+LF produce different results.
The result of parsing, therefore, passes original whitespace to the
application. Thus:
two spaces
and
two spaces
are different documents.
So are:
no line feeds
and
no line feeds
The first will confuse anyone accustomed to HTML only. The second will also
confuse them, and in addition will confuse some current users of SGML.
> >
> > Paul Prescod
>
> Is it up to the application to decide what to do with any leading line
> ending code in these positions then?
>
> I am pleased to be rid of the 'record' concept (using RS and RE)
> defined for SGML, particularly as I have tended to use Mac and UNIX
> systems which use a single character to end a line (albeit different
> ones!). However, I still think there is too little information on the
> effect of line ending codes in mixed content. Obviously the safe thing
> to do is to make the content of all elements with a mixed content
> model fit on a single line, as in:
>
>
This is a long paragraph.........................
>
> But with large text blocks, created using text editors, people will
> continue to use line ending codes to make it readable on-screen.
> Normally, a break between words would be interpreted as a space when
> the block is paginated:
>
>
This is a long paragraph that is broken over two
> lines, with an implied space between 'two' and 'lines'.
Yes. Most people will want to work this way. Very long lines are a menace
for many types of software. We must assume (and in many cases encourage)
people will read and even edit XML documents with non-XML tools.
>
> Yet what happens when a comment or processing instruction
> appears on its own line?
>
>
This is a long paragraph that is broken over two
>
> lines, with an implied space between 'two' and 'lines'.
>
> Is this interpreted as "two lines...", which reduces
> to "two lines"?
No. it reduces (I think) to:
"...two
lines..."
If there is one single 'obvious' issue which will prevent the take-up of XML
by 'ordinary' people (like myself) it is whitespace. The present position
on whitespace is:
- the rules are clear but not prescriptive
- the rules are non-intuitive to most people
- the rules allow many different ways of processing a given document
- the role of whitespace in a given document will depend on the
software used to process it
The philosophy of the XML-lang authors is consistently:
- whitespace is a problem for the application, not the spec.
- there is no generic way of treating whitespace
[I should make it clear that this isssue has been debated at great length,
and that the present position is the considered opinion of many experts.
I accept it, although I think it will be difficult to work with in practice.]
Without consistent treatment, a document author has to ask
'which application is going to process my document?'
It means, for example, that the way that whitespace is treated in MathML
may be different from that in CML and FooML and ... It effectively
destroys the possibility of (sub)document re-use, without a generally agreed
convention.
I know that XML-lang authors read this group and may therefore
take some of these points on board.
P.
>
>
> Neil.
>
>
> -----------------------------------------------
> Neil Bradley - Author of The Concise SGML Companion.
> neil@bradley.co.uk
> www.bradley.co.uk
>
> xml-dev: A list for W3C XML Developers
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To unsubscribe, send to majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
>
>
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From tbray at textuality.com Sat Aug 2 21:03:46 1997
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 16:58:12 2004
Subject: Specification Questions
Message-ID: <3.0.32.19970802115011.0089c5e0@pop.intergate.bc.ca>
At 09:51 AM 02/08/97 GMT, Peter Murray-Rust wrote:
>
>What whitespace characters can be passed to the application? Regardless of
>what is done with it, is CR+LF treated in the same way as LF or CR alone
>in a document?
>
All bytes that are not markup are data, and passed to the application.
Yes, this will be surprising to people who are used to HTML. Too bad -
HTML's behavior is unacceptable for many classes of applications. It
would be surprising to those who understand the 8879 rules, but
experience shows that this group includes only about a dozen people,
and they disagree. The rule given above has the virtue that it is
short, simple, and easily understood by everyone. We spent a lot
of time on this, and it's the only sane way to go. -Tim
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From john at datachannel.com Sun Aug 3 06:21:34 1997
From: john at datachannel.com (John Tigue)
Date: Mon Jun 7 16:58:12 2004
Subject: Xapi-J: an architectural detail (long)
Message-ID: <33E407E3.37404793@datachannel.com>
This note explains some of the internal implementation details of Xapi-J
compliant processors. If all you want to do is use an Xapi-J processor,
you do not need to concern yourself with these details. This note is
intended for people who are actually writing Xapi-J processors.
One of the nice features of Java is the clear distinction between
inheritance and interfaces. Xapi-J tries to leverage Java interfaces to
provide
processor users a simple object model and processor implementors wide
latitude
in regards to the processor internals..
Folks don't really have a problem grasping the XML object model:
To get a new XML processor object instance:
xml.XMLProcessor xmler = new xml.XMLProcessor();
To have a processor read a document:
xml.IDocument aDocument = xmler.readXML( someInfoSource );
To get the root of a document:
xml.IElement anElement = aDocument.getRoot();
To get an element's attributes:
java.util.Enumeration someAttributes = anElement.getAttributes();
That's easy to understand. It is a very simple object model
which can be mapped onto many of the current XML processors without
requiring major rewrites.
The greatest confusion centers around the mechanism used to hide the
specifics of the underlying implementation of the XML processor. This is
the only part of Xapi-J which actually involves real classes as opposed
to simply interfaces. Xapi-J does not contain an XML processor, it
simply says what one could look like. It is up to others to actually
supply the working code which is accessed through the Xapi-J interfaces.
One of the goals of Xapi-J is to create an architecture which (although
powerful and flexible) makes simple things simple. Navigating an XML
document object should be simple and as can be seen from the above code
fragments, it is. And getting an XML processor should be simple. That it
is. If a JVM comes with an installed XML processor, in the interests of
making things easy for developers, that processor should be used by
default. So a developer could simple do a "new xml.XMLProcessor();" and
expect that an XMLProcessor will be instantiated and usable. So if, say,
Microsoft wished to package their JVM with an XMLProcessor, they could
tweek the default constructor for xml.XMLProcessor to where it would
instantiate a com.ms.xml.Parser by default.
(I have tested that Xapi-J can be implemented on top of msxml. I have
the code on my hard drive. If anyone is interested drop me an email and
I'll give you the classes. With this interface adaptor, a developer
could write Java applets which save some download time by using the MS
parser which will be on the IE4 client and only downloading the light
weight adaptor. I would not suggest this. As I have mentioned in an
earlier posting I feel that the msxml object model is serious flawed.
Correcting for it required some non-optimal efficiency code.)
A good architecture makes simple things simple but it doesn't limit a
developer. Say a developer wanted to use an XML processor which was
tweeked for parsing MathML documents (call it MathMLProcessor). Perhaps
a MathMLProcessor could only understand that particular XML application
but via this specialization was able to obtain greater performance than
a general purpose XML processor. It would be great if the developer
could specify that when a "new xml.XMLProcessor()" call occurs a
MathMLProcessor should be instantiated. Xapi-J allows for this via the
following method in the xml.XMLProcessor class:
public static synchronized void setIXMLProcessorFactory(
IXMLProcessorFactory factorySettee ) throws XMLException
The method signature is that way because:
public:
accessible from other packages
static:
applies the the class in general not a particular instance
synchronized:
thread-safe access to a static method is usually advisable
void:
standard JavaBean accessor method signature design pattern is:
TypeOfX getX() AND void setX( TypeOfX xToBe )
setIXMLProcessorFactory:
this method sets the class's IXMLProcessorFactory
IXMLProcessorFactory:
an Xapi-J interface for objects which can be asked to create
objects
which implement the interface IXMLProcessor. During "new
xml.XMLProcessor()" the factory will be asked to instantiation an
object which implements IXMLProcessor
factorySettee:
The object which is to be assigned as the factory
throws XMLException:
a general XML exception object; might be thrown if the
factory had already been set (a security concern expressed in the
regular JDK fashion)
So the developer could do the following:
XMLProcessor.setIXMLProcessorFactory( new MathMLProcFactory() );
XMLProcessor xmler = new XMLProcessor();
Here the developer using an Xapi-J compliant processor needs to do just
one special line of code (tell the XMLProcessor class that it should
ask the specified MathMLProcFactory object to create IXMLProcessor's).
After that all the implementation specific details of the
MathMLProcessor are hidden behind the Xapi-J interfaces i.e. just do a
"new XMLProcessor()" and access the document through Xapi-J interfaces.
This is possible because even though the class XMLProcessor is the only
real class in Xapi-J, it is essentially hollow. A XMLProcesssor instance
is not really an XML processor. Xapi-J does not include an XML
processor, just the interface to one. All an XMLProcessor does is
act as a proxy to an object which implements IXMLProcessor. The
IXMLProcessor object is instantiated by the above mentioned factory. So
in the source code for the XMLProcessor class we see something like
the following code fragments:
// Class static factory code:
private static IXMLProcessorFactory processorFactory;
public static synchronized void setIXMLProcessorFactory(
IXMLProcessorFactory factorySettee ) throws XMLException
{
processorFactory = factorySettee;
}
// Instance constructor code:
private IXMLProcessor implementation;
public XMLProcessor ()
{
this.implementation = processorFactory.createIXMLProcessor();
}
// instance action code:
public IDocument readXML( Object xmlSource ) throws XMLException
{
return implementation.readXML( xmlSource );
}
The execution sequence looks like:
1. The factory is set via XMLProcessor.setIXMLProcessorFactory().
2. Later, a "new XMLProcessor()" happens.
3. In the constructor the factory is asked to return an IXMLProcessor.
4. The IXMLProcessor object is assigned to the field "implementation".
5. Later, a "readXML()" call happens.
6. In readXML(), the XMLProcessor object, acting as a proxy, passes
the request onto its IXMLProcessor and then,
7. The XMLProcessor object returns whatever is returned to it from its
IXMLProcessor. I.e. class IXMLProcessor is the real worker.
So the phrase "Xapi-J contains no XML processor" could more precisely be
stated as: Xapi-J does contain a class XMLProcessor but it does not
contain an implementation of the interface IXMLProcessor which is the
real worker/processor in the Xapi-J architecture.
The above is a convoluted dance but to the developer who is simply using
an Xapi-J compliant XML processor it looks really simple on the outside.
(For a very similar "design patter" see java.net.Socket et al.) And only
one
API has to be learned to work with any Xapi-J compliant processor.
--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue@datachannel.com
206-462-1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970803/36d826f5/vcard.vcf
From Peter at ursus.demon.co.uk Sun Aug 3 15:58:14 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:12 2004
Subject: Specification Questions
Message-ID: <9091@ursus.demon.co.uk>
In message <199708020838.JAA11135@andromeda.ndirect.co.uk> "Neil Bradley" writes:
[...]
>
This is a long paragraph that is broken over two
>
> lines, with an implied space between 'two' and 'lines'.
>
> Is this interpreted as "two lines...", which reduces
> to "two lines"?
Some additional - hopefully constructive - thoughts on whitespace.
The XML-lang spec does not ( and I suspect will not) give detailed guidance
on how whitespace will be managed. My impression is that it is up to
implementers and/or groups like this to come up with particular solutions.
My worry is that these will be inconsistent and not inter-operable.
***
Therefore I propose that those on XML-DEV who care about this problem come
up with some guidelines for implementers.
***
XML does NOT treat whitespace like SGML and does NOT behave like HTML
(although it can be configured to do so). As far as I see them, the rules
are:
'All characters that are not markup are passed to the application'. (This
is independent of any value of XML-SPACE (see below), processing instructions,
stylesheets, etc.) These characters include HT, CR, LF, SP, and probably
a number of other Unicode 'whitespace' characters. What the application
does with them is *undefined* in XML-lang.
Note that this means that CR and LF are passed as separate characters. No
normalisation takes place. Therefore
Line one\n\rline two
is different from
Line one\nline two
even if they are visually similar on various text editors/displays, etc.
(My impression was that SGML normalised these two strings to the same
ESIS output - is that right?).
This means that the author/processor 'contract' has to be aware of this.
Note also that *all* line-ends are passed (even immediately before/after
markup) unlike SGML. Therefore:
line one
and
line one
are different.
Note also that:
baz
is different from
baz
The latter contains two pseudo-elements which contain only whitespace
(line-end characters) and FOO therefore has three children.
[Note that to make documents readable, the following trick can be used:
baz
since whitespace within the tag is ignored. I do not think newcomers will
adopt this easily, and I suspect it can lead to errors in document editing.]
*** In some cases the document author and the application author are both
aware of this problem and so the whitespace characters inserted by the
author will be processed in the way that they expect. However, in most cases
I suspect this will NOT be true and that authors will inadvertently create
documents that are processed differently ***
XML provides an attribute XML-SPACE (local to an element BUT inherited by
its children) which can have three values:
- #IMPLIED (no signals about whitespace handling)
- PRESERVE (applications preserve all the whitespace)
- DEFAULT (the *application's* default white-space processing modes
are acceptable fro this element).
PRESERVE seems clear. All whitespace is passed to the application. The
others seem to be dangerous unless there are some general conventions.
[Note also that XML parsers or processors have to ensure that children
inherit the XML-SPACE attributes of their parents. Where does this get
done? In the parser? (It's part of XML-lang), in the processor - in which
case there is ample scope for inconsistent treatment...
Inheritance is already required in two places - XML-SPACE and XML-ATTRIBUTES
(XML-link). This is a generic mechanism and presumably should be implemented
in some package independenetly of the application. Comments?]
If possible, we should propose a *general* default mechanism for whitespace
handling for XML-SPACE="DEFAULT". If everyone adopts this, it will greatly
reduce this problem. Is this a reasonable strategy?
If so, we can propose that the DEFAULT mode for any whitespace processing is
something along the lines (similar to HTML?). Within an element with
XML-SPACE="DEFAULT"
All whitespace sequences are mapped into a single space character.
All whitespace pseudo-elements are ignored (i.e. whitespace between markup)
All leading and trailing whitespace in #PCDATA is ignored.
Does this cover everything? Is it workable?
Example:
this
isa
bar
folds to:
this is a bar
[Note that the Xpointer STRING syntax and the use of pseudo-elements
works on the *raw* data (i.e. all non-markup characters). Therefore the
application has to have access to this - it has to maintain a PRESERVEd
version of the document as well as (say) displaying or transforming a
DEFAULTed document.]
I think it's important to address this, since otherwise I predict we shall
have considerable confusion, especially when implementors of authoring or
processing software have not thought this through completely.
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From Peter at ursus.demon.co.uk Sun Aug 3 15:58:25 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:12 2004
Subject: Xapi-J: an architectural detail (long)
Message-ID: <9092@ursus.demon.co.uk>
John,
Thanks very much for this - including keeping the momentum of this effort.
I encourage other memebrs of this list to react to this posting - John
has obviously worked very hard at this.
In message <33E407E3.37404793@datachannel.com> john@datachannel.com (John Tigue) writes:
[...]
>
> Folks don't really have a problem grasping the XML object model:
>
> To get a new XML processor object instance:
> xml.XMLProcessor xmler = new xml.XMLProcessor();
>
> To have a processor read a document:
> xml.IDocument aDocument = xmler.readXML( someInfoSource );
>
> To get the root of a document:
> xml.IElement anElement = aDocument.getRoot();
>
> To get an element's attributes:
> java.util.Enumeration someAttributes = anElement.getAttributes();
>
> That's easy to understand. It is a very simple object model
> which can be mapped onto many of the current XML processors without
> requiring major rewrites.
I follow all this. Can we also go one step further and say how we get
the children of an Element. I am assuming also that (say) the DTD is
not a child of root in this model - do you have proposals for all this?
If so, please post them :-) so we can get it finished - we keep going round
and round on this ...
>
[...]
>
> (I have tested that Xapi-J can be implemented on top of msxml. I have
Excellent! What are your thoughts about NXP and Lark?
[...]
>
> The execution sequence looks like:
> 1. The factory is set via XMLProcessor.setIXMLProcessorFactory().
> 2. Later, a "new XMLProcessor()" happens.
> 3. In the constructor the factory is asked to return an IXMLProcessor.
> 4. The IXMLProcessor object is assigned to the field "implementation".
> 5. Later, a "readXML()" call happens.
> 6. In readXML(), the XMLProcessor object, acting as a proxy, passes
> the request onto its IXMLProcessor and then,
> 7. The XMLProcessor object returns whatever is returned to it from its
> IXMLProcessor. I.e. class IXMLProcessor is the real worker.
>
> So the phrase "Xapi-J contains no XML processor" could more precisely be
>
> stated as: Xapi-J does contain a class XMLProcessor but it does not
> contain an implementation of the interface IXMLProcessor which is the
> real worker/processor in the Xapi-J architecture.
>
> The above is a convoluted dance but to the developer who is simply using
>
> an Xapi-J compliant XML processor it looks really simple on the outside.
>
> (For a very similar "design patter" see java.net.Socket et al.) And only
> one
> API has to be learned to work with any Xapi-J compliant processor.
I think I have followed John's logic and proposal, and suggest that we take
this as a concrete proposal. Since it's only likely to be used by a smallish
number of people, its apparent complexity is acceptable. For example, JUMBO
is able to use more than one parser, but I have to delve into each one to
see how to extract the correct aprts. This would make it easier overall.
Assuming we accept this I'd like us also to tackle the question of Nodes,
Elements, etc. Until this is done it's difficult to build application
software with interchangeable parts. For example, there is a lot of generic
stuff (see my posting on whitespace) that an XML application (?processor)
has to implement, and hopefully we can isolate and standardise on that.
Once again, thanks John.
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From john at datachannel.com Mon Aug 4 00:11:29 1997
From: john at datachannel.com (John Tigue)
Date: Mon Jun 7 16:58:12 2004
Subject: Xapi-J: an architectural detail
References: <9092@ursus.demon.co.uk>
Message-ID: <33E502A7.80A66A68@datachannel.com>
Peter Murray-Rust wrote:
>
> > To get an element's attributes:
> > java.util.Enumeration someAttributes =
> anElement.getAttributes();
> >
> I follow all this. Can we also go one step further and say how we get
>
> the children of an Element.
To get an element's children: java.util.Enumeration children =
anElement.getContents();
This method returns an Enumeration, each object of which implements
IContent. The below paragraphs explain IContent et al.
An XML document can be represented as a tree. In an XML document object
model there are things which are containers (e.g. a document is a
container and so is an element) and also things which are the content of
a container (e.g. a chunk of text is a content or even a element can be,
in the case of one element within another). To model these there are the
IContainer and IContent interfaces. The full source follows:
public interface IContainer
{
public Enumeration getContents();
public void insertContent( IContent aContent, IContent
preceedingContent );
public void appendContent( IContent aContent );
public void removeContent( IContent aContent );
}
public interface IContent
{
public void setParent( IContainer aContainer );
public IContainer getParent();
public String getData();
}
These interfaces only express the methods for navigating a tree. A
particular class of objects would need to have some more methods to be
interesting. For example, the interface for an element is IElement. The
full source follows:
public interface IElement extends IContent, IContainer
{
public String getType();
public void setType( String aType );
public void addAttribute( String name, String value );
public void removeAttribute( String name );
public IAttribute getAttribute( String attributeName );
public java.util.Enumeration getAttributes();
}
The above states that an IElement can be a container and/or a content
and also has some other methods particular to being an element. So
although IElement does not directly have a method called getContents(),
it gets the method from its superinterface IContainer.
(Note that the Xapi-J method getType() follows the terminology of
XML-LANG and as such it implies completely different semantics than
com.ms.xml.Element.getType(). Xapi-J's getType() returns a String which
is the "Name" from production [33] of the spec. For example, in the
following:
red
The spec clearly says "The Name in the start-and end-tags gives the
element's type" so for the above example in Xapi-J getType() would
return a String with the value "color" not an int with the value 1 (i.e.
MS's ELEMENT constant). Microsoft has chosen an independent model in
which most objects in a document are com.ms.xml.Element and the
particular flavor of "Element" is determined through the getType()
method. In that model all of the following are "Element" types:
DOCUMENT, ELEMENT, PCDATA, PI, BETA, COMMENT, and CDATA.).
>
> > (I have tested that Xapi-J can be implemented on top of msxml. I
> have
>
> Excellent! What are your thoughts about NXP and Lark?
>
Lark maps very easily to Xapi-J. Xapi-J was designed by taking all the
best ideas from the existing processors so the mappings are
straight-forward. NXP is pretty much the standard when it comes to ESIS
output so it defines that part of Xapi-J making the mapping essentially
direct. The only new part is the stuff mentioned in the posting which
started this thread: how does a developer instantiate a processor
through the Xapi-J interfaces. After that it's the regular old NXP
stuff.
Note that since Xapi-J is pretty much just a bunch of interfaces, this
work can easily be fit into a full grove model. The objects in the grove
could implement their grove interfaces and if desirable also implement
the earlier Xapi-J interfaces. A full grove model is being work on by
others so making Xapi-J a full grove model would be a duplication of
effort. The main goal of Xapi-J is simply to make things easier for
developers using the current crop of processors.
--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue@datachannel.com
206-462-1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970803/be6c700d/vcard.vcf
From Peter at ursus.demon.co.uk Mon Aug 4 09:01:09 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:12 2004
Subject: Xapi-J: an architectural detail
Message-ID: <9106@ursus.demon.co.uk>
In message <33E502A7.80A66A68@datachannel.com> john@datachannel.com (John Tigue) writes:
[...]
> Lark maps very easily to Xapi-J. Xapi-J was designed by taking all the
> best ideas from the existing processors so the mappings are
> straight-forward. NXP is pretty much the standard when it comes to ESIS
> output so it defines that part of Xapi-J making the mapping essentially
> direct. The only new part is the stuff mentioned in the posting which
> started this thread: how does a developer instantiate a processor
> through the Xapi-J interfaces. After that it's the regular old NXP
> stuff.
Sounds good to me. I am particulalry impressed by the fact that you can
make it work with the various parsers, even if they take different approaches
with different terms.
What is your timescale for putting it all together? Are there any places where
you need more feedback from the list? FWIW it gets my vote :-)
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From richard at light.demon.co.uk Mon Aug 4 12:24:12 1997
From: richard at light.demon.co.uk (Richard Light)
Date: Mon Jun 7 16:58:12 2004
Subject: Xapi-J: an architectural detail
In-Reply-To: <33E502A7.80A66A68@datachannel.com>
Message-ID: <1r1HGKAKwa5zEwZY@light.demon.co.uk>
In message <33E502A7.80A66A68@datachannel.com>, John Tigue
writes
>
>An XML document can be represented as a tree. In an XML document object
>model there are things which are containers (e.g. a document is a
>container and so is an element) and also things which are the content of
>a container (e.g. a chunk of text is a content or even a element can be,
>in the case of one element within another). To model these there are the
>IContainer and IContent interfaces. The full source follows:
>
>public interface IContainer
> {
> public Enumeration getContents();
> public void insertContent( IContent aContent, IContent
>preceedingContent );
> public void appendContent( IContent aContent );
> public void removeContent( IContent aContent );
> }
>
>public interface IContent
> {
> public void setParent( IContainer aContainer );
> public IContainer getParent();
> public String getData();
> }
These interfaces are mirrored in the SGML/XML Property Set. In that,
everything is a 'node', each with its own name and a set of properties.
One of those properties is 'subnode' - having a subnode property makes a
node, de facto, into a Container in your terminology. The complete XML
document can be represented as a 'grove' (tree structure) of these
nodes.
The parent-child relationship between elements of the XML document is
more specific than this. The full grove includes things like the DTD
and processing instructions, which are nodes in the grove structure but
do not exhibit 'parent-child' relationships to anything else.
Nodes have some 'intrinsic properties', which apply whatever their
particular type might be. (Again, this mirrors your thinking very
closely.) These intrinsic properties are:
object Node
property ClassNm ; the name of the node's class
property GrovRoot ; the root of the grove of which the node forms a
part
property SunPNs ; the names of all the subnode properties exhibited
by the node
property AllPNs ; the names of all the properties exhibited by the
node
property ChildPN ; the name of the children property, when this class
of node has children
property DataPN : the data property name (i.e. 'char' or 'string'),
when this class of node contains data
property DSepPN ; the data separator property name
property Parent ; the node's parent
property TreeRoot ; the root of the parent-children tree [not the same
as the 'grove root']
property Origin ; the node that that this node as one of its subnode
properties
property OTSRelPN ; the origin-to-subnode relationship property name
I've given the full set of intrinsic node properties, really just to
point out that all of this modeling has already been done before. Much
of it is too detailed (and perhaps one level too abstract) to apply to
Xapi-J. However, I'm concerned that Xapi-J developers shouldn't just
ignore the SGML property set and invent their own version.
Expressing the only intrinsic property (parent) that is relevant to this
discussion leads to:
public interface XMLnode
{
public XMLnode parent();
}
We could add in a couple of extra intrinsic properties, so you can get
to the grove root and its origin from any node:
public interface XMLnode
{
public XMLnode parent();
public XMLnode grovroot();
public XMLnode origin();
}
I don't think we need separate IContainer and IContent interfaces -
what's wrong with just INode (or XMLnode, as I have it)?
>These interfaces only express the methods for navigating a tree. A
>particular class of objects would need to have some more methods to be
>interesting. For example, the interface for an element is IElement. The
>full source follows:
>
>public interface IElement extends IContent, IContainer
> {
> public String getType();
> public void setType( String aType );
> public void addAttribute( String name, String value );
> public void removeAttribute( String name );
> public IAttribute getAttribute( String attributeName );
> public java.util.Enumeration getAttributes();
> }
>
>The above states that an IElement can be a container and/or a content
>and also has some other methods particular to being an element. So
>although IElement does not directly have a method called getContents(),
>it gets the method from its superinterface IContainer.
We can do the same thing here:
public interface XMLelement extends XMLnode
{
public String gi();
public void setType( String aType );
public void addAttribute( String name, String value );
public void removeAttribute( String name );
public XMLattribute getAttribute( String attributeName );
public XMLattlist atts();
}
Notice that I've left the middle four declarations more or less
unchanged, for the following reason:
There is definitely a useful distinction here, between those things
which are _properties_ of a node within an XML document, like the GI of
an element or its list of declared attributes, and _operations_ which
the API lets you carry out on that node.
The SGML/XML property set is entirely about the properties of an
existing instance. It provides no framework or precedent for API
commands which _alter_ that instance, like SetType (which assigns or
changes the GI of an element). There, we are rather more on our own!
I'm not sure if the Java API provides for a more elegant way of
specifying a property than the one I've dreamt up - if it does, we
should use it.
Hope this helps.
Richard Light
SGML and Museum Information Consultancy
richard@light.demon.co.uk
3 Midfields Walk
Burgess Hill
West Sussex RH15 8JA
U.K.
tel. (44) 1444 232067
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From john at datachannel.com Mon Aug 4 18:54:11 1997
From: john at datachannel.com (John Tigue)
Date: Mon Jun 7 16:58:12 2004
Subject: Xapi-J: an architectural detail
References: <1r1HGKAKwa5zEwZY@light.demon.co.uk>
Message-ID: <33E609C6.6EEE0CB9@datachannel.com>
Richard Light wrote:
> In message <33E502A7.80A66A68@datachannel.com>, John Tigue
> writes
> >
> >An XML document can be represented as a tree. In an XML document
> object
> >model there are things which are containers (e.g. a document is a
> >container and so is an element) and also things which are the content
> of
> >a container (e.g. a chunk of text is a content or even a element can
> be,
> >in the case of one element within another). To model these there are
> the
> >IContainer and IContent interfaces. The full source follows:
> >
> >public interface IContainer
> > {
> > public Enumeration getContents();
> > public void insertContent( IContent aContent, IContent
> >preceedingContent );
> > public void appendContent( IContent aContent );
> > public void removeContent( IContent aContent );
> > }
> >
> >public interface IContent
> > {
> > public void setParent( IContainer aContainer );
> > public IContainer getParent();
> > public String getData();
> > }
>
> These interfaces are mirrored in the SGML/XML Property Set. In that,
> everything is a 'node', each with its own name and a set of
> properties.
> One of those properties is 'subnode' - having a subnode property makes
> a
> node, de facto, into a Container in your terminology. The complete
> XML
> document can be represented as a 'grove' (tree structure) of these
> nodes.
>
I agree that grove is the way to go. I'm just trying to get all the
current processors on the same track before we move towards the grove
work.
> The parent-child relationship between elements of the XML document is
> more specific than this. The full grove includes things like the DTD
> and processing instructions, which are nodes in the grove structure
> but
> do not exhibit 'parent-child' relationships to anything else.
>
How will we represent the DTD in order to reflect the effects of the
Bray Namespace Proposal?
> Nodes have some 'intrinsic properties', which apply whatever their
> particular type might be. (Again, this mirrors your thinking very
> closely.) These intrinsic properties are:
>
> object Node
> property ClassNm ; the name of the node's class
> property GrovRoot ; the root of the grove of which the node forms a
> part
> property SunPNs ; the names of all the subnode properties
> exhibited
> by the node
> property AllPNs ; the names of all the properties exhibited by the
>
> node
> property ChildPN ; the name of the children property, when this
> class
> of node has children
> property DataPN : the data property name (i.e. 'char' or
> 'string'),
> when this class of node contains data
> property DSepPN ; the data separator property name
> property Parent ; the node's parent
> property TreeRoot ; the root of the parent-children tree [not the
> same
> as the 'grove root']
> property Origin ; the node that that this node as one of its
> subnode
> properties
> property OTSRelPN ; the origin-to-subnode relationship property name
>
> I've given the full set of intrinsic node properties, really just to
> point out that all of this modeling has already been done before.
> Much
> of it is too detailed (and perhaps one level too abstract) to apply to
>
> Xapi-J. However, I'm concerned that Xapi-J developers shouldn't just
> ignore the SGML property set and invent their own version.
>
Ignoring the SGML property set would be just plain stupid. I like to
drive cars not re-invent wheels.
> Expressing the only intrinsic property (parent) that is relevant to
> this
> discussion leads to:
>
> public interface XMLnode
> {
> public XMLnode parent();
> }
>
> We could add in a couple of extra intrinsic properties, so you can get
>
> to the grove root and its origin from any node:
>
> public interface XMLnode
> {
> public XMLnode parent();
> public XMLnode grovroot();
> public XMLnode origin();
> }
>
I absolutely agree that the Xapi-J interfaces are not done. I have tried
to bring the current processors together while mapping out the basics of
the object model. We will need to add more properties as you point out.
One thing I would like to see is that we return appropriate objects as
much as possible. One particular processor out there does a
getAttribute() where you pass in a String and get back a String. I think
an IAttribute should be returned. This way other convenience methods of
the returned class can be used. For example something like isPercent()
or isNumeric() for an attribute not to mention all the properties of say
a character.
> I don't think we need separate IContainer and IContent interfaces -
> what's wrong with just INode (or XMLnode, as I have it)?
>
We could do that. Or maybe both with something like the following:
public interface XMLNode extends IContainer, IContent
{
...
}
I went with IContainer and IContent because I can do more precise
polymorphic message handling such that the receiving method can make
more assumptions about what the passed object can do without casting to
the exact class. Casting in Java is a runtime cost (b/ of security) so
more expensive.
> >These interfaces only express the methods for navigating a tree. A
> >particular class of objects would need to have some more methods to
> be
> >interesting. For example, the interface for an element is IElement.
> The
> >full source follows:
> >
> >public interface IElement extends IContent, IContainer
> > {
> > public String getType();
> > public void setType( String aType );
> > public void addAttribute( String name, String value );
> > public void removeAttribute( String name );
> > public IAttribute getAttribute( String attributeName );
> > public java.util.Enumeration getAttributes();
> > }
> >
> >The above states that an IElement can be a container and/or a content
>
> >and also has some other methods particular to being an element. So
> >although IElement does not directly have a method called
> getContents(),
> >it gets the method from its superinterface IContainer.
>
> We can do the same thing here:
>
> public interface XMLelement extends XMLnode
> {
> public String gi();
> public void setType( String aType );
> public void addAttribute( String name, String value );
> public void removeAttribute( String name );
> public XMLattribute getAttribute( String attributeName );
> public XMLattlist atts();
> }
>
I generally argree. I went for getGI() and setGI() at one point but the
spec forced getType() and setType(). Plus I believe that the work we
produce here will filter down to folks who are far less preoccupided
with XML. For them the term "generic identifier" or even "gi" would be
less readily grasped than "type". Either way, by following the get/set
naming convention we map to JavaBeans. Slightly more wordy than X() and
setX() but the builder tools are geared for recognising getX() and
setX().
> Notice that I've left the middle four declarations more or less
> unchanged, for the following reason:
>
> There is definitely a useful distinction here, between those things
> which are _properties_ of a node within an XML document, like the GI
> of
> an element or its list of declared attributes, and _operations_ which
> the API lets you carry out on that node.
>
> The SGML/XML property set is entirely about the properties of an
> existing instance. It provides no framework or precedent for API
> commands which _alter_ that instance, like SetType (which assigns or
> changes the GI of an element). There, we are rather more on our own!
>
At first setType() might seem less than useful. And perhaps type should
be a parameter to the constructor and not modifiable (more on that
later). I got caught in a Java specific detail related to the
following:Class.forName("SomeClass").newInstance()
With this code Java objects can be instantiated from a String of the
class' name. That's handy for object serialization amongst other things;
for example, say you had a repository of classes for specific element
types and you want to instantiate one during a parse. The point is that
in Java newInstance() only works with the default constructor;
parameters cannot be passed in. So there is need for a seperate method
for setting the type of the element. If we wanted to make the type
immutable then perhaps we could specify that the member field "type" can
only be set once. This type of behavior shows up a lot in the JDK.
Inside the property setter the field is checked for null, if not then
produce an exception. Also in the JDK we see String and StringBuffer
where String is immutable and StringBuffer is where strings can be
dynamically built up. Perhaps something like that for Xapi-J
> I'm not sure if the Java API provides for a more elegant way of
> specifying a property than the one I've dreamt up - if it does, we
> should use it.
>
The only point I'm sure on is the getX() and setX() "design pattern".
Most Java devs casually consuming XML will use a JavaBean and we should
plan for that architecture.
> Hope this helps.
>
Deffinately. Thanks.
> Richard Light
> SGML and Museum Information Consultancy
> richard@light.demon.co.uk
> 3 Midfields Walk
> Burgess Hill
> West Sussex RH15 8JA
> U.K.
> tel. (44) 1444 232067
>
> xml-dev: A list for W3C XML Developers
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To unsubscribe, send to majordomo@ic.ac.uk the following message;
> unsubscribe xml-dev
> List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue@datachannel.com
206-462-1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970804/bfb1fb6e/vcard.vcf
From andrewl at microsoft.com Tue Aug 5 00:03:26 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:13 2004
Subject: Process: Subjects of Messages (was "A question and a proposal")
Message-ID: <7BB61B44F197D011892800805FD4F7920133B7A8@RED-03-MSG.dns.microsoft.com>
It would be helpful if authors would give their messages titles that are
meaningful descriptions of the substantive contents of the message.
Something like "A question and a proposal" is cute, but useless for
filing.
--Andrew Layman
AndrewL@microsoft.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From akirkpatrick at ims-global.com Tue Aug 5 10:14:39 1997
From: akirkpatrick at ims-global.com (akirkpatrick@ims-global.com)
Date: Mon Jun 7 16:58:13 2004
Subject: Xapi-J: an architectural detail
Message-ID:
I really like the combination of IContent and IContainer.
The only question I have is how an element can query
its context in an efficient way? For example, how can
I find the previous element without referring to the parent
container. Presumably then the parent would have to
enumerate all its children to find the previous content
to the element in question. Obviously a particular
application can record the previous element in a variable
but then you get to more complex contexts, like "what
is the previous of my parent".
Any thoughts?
Alfie.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From neil at bradley.co.uk Tue Aug 5 11:49:56 1997
From: neil at bradley.co.uk (Neil Bradley)
Date: Mon Jun 7 16:58:13 2004
Subject: Specification Questions
Message-ID: <199708050949.KAA07792@andromeda.ndirect.co.uk>
Reply-to: Peter@ursus.demon.co.uk (Peter Murray-Rust)
> Some additional - hopefully constructive - thoughts on whitespace.
>
> The XML-lang spec does not ( and I suspect will not) give detailed guidance
> on how whitespace will be managed. My impression is that it is up to
> implementers and/or groups like this to come up with particular solutions.
> My worry is that these will be inconsistent and not inter-operable.
I agree totally. This was my original concern.
> ***
> Therefore I propose that those on XML-DEV who care about this problem come
> up with some guidelines for implementers.
> ***
I very much hope this happens.
> XML does NOT treat whitespace like SGML and does NOT behave like HTML
> (although it can be configured to do so). As far as I see them, the rules
> are:
>
> 'All characters that are not markup are passed to the application'. (This
> is independent of any value of XML-SPACE (see below), processing instructions,
> stylesheets, etc.) These characters include HT, CR, LF, SP, and probably
> a number of other Unicode 'whitespace' characters. What the application
> does with them is *undefined* in XML-lang.
>
> Note that this means that CR and LF are passed as separate characters. No
> normalisation takes place. Therefore
>
> Line one\n\rline two
>
> is different from
>
> Line one\nline two
>
> even if they are visually similar on various text editors/displays, etc.
> (My impression was that SGML normalised these two strings to the same
> ESIS output - is that right?).
>
> This means that the author/processor 'contract' has to be aware of this.
I think all applications should be expected to either or both
characters in sequence as a line end signal, so that platform
dependancies can be eliminated. If there is no good reason to omit
this taks from the XML-processor itself, I think it should be done
there.
> *** In some cases the document author and the application author are both
> aware of this problem and so the whitespace characters inserted by the
> author will be processed in the way that they expect. However, in most cases
> I suspect this will NOT be true and that authors will inadvertently create
> documents that are processed differently ***
>
> XML provides an attribute XML-SPACE (local to an element BUT inherited by
> its children) which can have three values:
> - #IMPLIED (no signals about whitespace handling)
> - PRESERVE (applications preserve all the whitespace)
> - DEFAULT (the *application's* default white-space processing modes
> are acceptable fro this element).
>
> PRESERVE seems clear. All whitespace is passed to the application. The
> others seem to be dangerous unless there are some general conventions.
> If possible, we should propose a *general* default mechanism for whitespace
> handling for XML-SPACE="DEFAULT". If everyone adopts this, it will greatly
> reduce this problem. Is this a reasonable strategy?
I believe so. In addition, can we not put 'XML-SPACE
(PRESERVE|IMPLIED) "PRESERVE" in an attribute declaration for an
element which will always have reserved content. It is common
practice for a DTD to have some kind of pre-formatted element, such
as HTML's '
'.
> If so, we can propose that the DEFAULT mode for any whitespace processing is
> something along the lines (similar to HTML?). Within an element with
> XML-SPACE="DEFAULT"
>
> All whitespace sequences are mapped into a single space character.
Agreed.
> All whitespace pseudo-elements are ignored (i.e. whitespace between markup)
Ummm. what about 'the bolditalic styles...'?
> All leading and trailing whitespace in #PCDATA is ignored.
I think all applications should remove leading and trailing CR and LF
characters in a mixed content element. But not SP or HT, as this would
be undesirable in the following fragment:
A bold word.
Although an unusual layout, some people may use it, and it would be
unfortunate if it resulted in 'Aboldword'.
> Example:
>
> this
>
> isa
DID YOU INTEND A SPACE SOMEWHERE BETWEEN 'is' AND 'a'?
> bar
>
>
> folds to:
> this is a bar
>
> I think it's important to address this, since otherwise I predict we shall
> have considerable confusion, especially when implementors of authoring or
> processing software have not thought this through completely.
Again, I agree, and I think it will be possible to achieve this with
a bit more discussion in this forum.
> Peter Murray-Rust, domestic net connection
Neil.
-----------------------------------------------
Neil Bradley - Author of The Concise SGML Companion.
neil@bradley.co.uk
www.bradley.co.uk
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From ricko at allette.com.au Tue Aug 5 15:12:30 1997
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 16:58:13 2004
Subject: XML and whitespace: lets just dump CR and LF!
Message-ID: <199708051317.XAA23619@jawa.chilli.net.au>
> From: Neil Bradley
> Reply-to: Peter@ursus.demon.co.uk (Peter Murray-Rust)
> > Therefore I propose that those on XML-DEV who care about this problem come
> > up with some guidelines for implementers.
> I very much hope this happens.
> > This means that the author/processor 'contract' has to be aware of this.
Can I suggest a very different tack?
The problem with CR/LF is one of overloading not of translation or contracts.
They have too many meanings. In particular they function both as
record-start/-end characters and as new-lines.
I suggest that the following approach should be taken. (I think it is the only
realistic solution, especially if we assume that 1) data is usually generated by applications, 2) humans only check and tweak data;
3) we want operating system
and character set independence, 4) line-breaking is generally done by clients
...so CR/LF is basically a convenience for fitting data into editors,
not for the purposes of output.)
**A) XML applications should ignore *ALL* CR and LF as a bad joke. They should
be entirely there for formatting the raw text into nice, eye-sized records.
So CR and LF should never be converted to spaces. (This approach was the
one taken by Interleaf, and I have come to appreciate it.) If you need a
space, then start the new line with it! (Ending the previous line is difficult
to see.)
**B) XML applications should mandate the use of the unambiguous Unicode characters
-- LINE SEPARATOR
-- PARAGRAPH SEPARATOR
So if I want to do the equivalent of HTML
X
XML can have:
X
or even
X
&x2028;
And it can do this with the text conventions of any operating system.
I certainly think that CR/LF should be not of interest to XML-lang. And I think
they should be of marginal interest to XML applications too. Lets dump them!
Rick Jelliffe
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From tbray at textuality.com Tue Aug 5 16:10:39 1997
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 16:58:13 2004
Subject: XML and whitespace: lets just dump CR and LF!
Message-ID: <3.0.32.19970805070023.0081f720@pop.intergate.bc.ca>
At 11:13 PM 05/08/97 +1000, Rick Jelliffe wrote:
>**A) XML applications should ignore *ALL* CR and LF as a bad joke......
>
>I certainly think that CR/LF should be not of interest to XML-lang...
>Lets dump them!
Heh-heh. If you go look in the proceedings of the 1988 Usenix conference,
you'll find a paper I wrote, on the Oxford English Dictionary project,
which has a section entitled
'\n' Considered Harmful
I'd love to lose the record-end silliness. Trouble is, we're stuck with
it until we have better editing tools. -T.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From clloyd at gorge.net Tue Aug 5 16:49:14 1997
From: clloyd at gorge.net (Chris Lloyd)
Date: Mon Jun 7 16:58:13 2004
Subject: Xapi-J: an architectural detail
In-Reply-To:
Message-ID: <3.0.1.32.19970805074603.006bcb18@gorge.net>
akirkpatrick wrote:
>I really like the combination of IContent and IContainer.
>The only question I have is how an element can query
>its context in an efficient way? For example, how can
>I find the previous element without referring to the parent
>container. Presumably then the parent would have to
>enumerate all its children to find the previous content
>to the element in question. Obviously a particular
>application can record the previous element in a variable
>but then you get to more complex contexts, like "what
>is the previous of my parent".
>
This is where the next step is needed. Tree Iterators can provide efficient
and well abstracted mechanisms for walking the XML tree. Everyone is still
stuck on the schema part of Xpia-j and that is fine. After that is done
then it's time to add classes specifically for navigation.
Keep the schema simple. Don't add members for the previous child, etc.. It
is unnecessary and complex to maintain.
Over the past 2 years, we have been developing an object database system
for SGML. We have gone through the same thought processes as are going on
with xapi-j right now. I think there are a few design considerations to
keep in mind if you want to use iterator classes with the xapi-j schema and
I think eventually you will.
The idea of inheriting from IContainer is a good one. Polymorphism is very
useful when it comes time to write navigation classes. A base class for all
objects in the tree is very important!! We'll call this INode.
It then becomes useful to break the type of nodes into 2 classes.
IContainer and IProperty. An IProperty is always a leaf node of the tree
and an IContainer is not. After that you add your concrete classes such as
IElement.
John Tigue wrote:
>These interfaces only express the methods for navigating a tree. A
>particular class of objects would need to have some more methods to be
>interesting. For example, the interface for an element is IElement. The
>full source follows:
>public interface IElement extends IContent, IContainer
> {
> public String getType();
> public void setType( String aType );
> public void addAttribute( String name, String value );
> public void removeAttribute( String name );
> public IAttribute getAttribute( String attributeName );
> public java.util.Enumeration getAttributes();
> }
In the above example the returned interface IAttribute would inherit from
IProperty because it is a leaf node.
A Tree Iterator would already now the structure of an element when it walks
over it an would know how to retrieve the attributes. When it walks on to
an attribute, it knows it's a leaf node because it inherits from IProperty.
Again I stress that every XML object in the tree should inherit from a
single base class even if the base class does not provide any common
interfaces to it's concrete classes. In this way, any XML object can be
passed via a base class reference(Whoops, I almost said pointer). It is
trivia to implement a fast, safe-casting mechanism that uses polymorphism
for casting.
This way, we can later add navigation classes that leverage the polymorphic
nature of the XML tree.
Chris Lloyd
POET Software
>Any thoughts?
>Alfie.
>
>xml-dev: A list for W3C XML Developers
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To unsubscribe, send to majordomo@ic.ac.uk the following message;
>unsubscribe xml-dev
>List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
>
>
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From andrewl at microsoft.com Tue Aug 5 18:55:19 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:13 2004
Subject: Linking and Query question
Message-ID: <7BB61B44F197D011892800805FD4F7920133B7BF@RED-03-MSG.dns.microsoft.com>
Can I create a link that, in effect, contains a query so that it
references one document among a set? For example, if I know that several
versions of a document exist, and I want to reference the latest
version, but I'm willing to accept either of the two prior versions, can
I express that? If so, how? Thanks.
--Andrew Layman
AndrewL@microsoft.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From tbray at textuality.com Tue Aug 5 19:10:53 1997
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 16:58:13 2004
Subject: Linking and Query question
Message-ID: <3.0.32.19970805100443.008bd6e0@pop.intergate.bc.ca>
At 09:54 AM 05/08/97 -0700, Andrew Layman wrote:
>Can I create a link that, in effect, contains a query so that it
>references one document among a set? For example, if I know that several
>versions of a document exist, and I want to reference the latest
>version, but I'm willing to accept either of the two prior versions, can
>I express that? If so, how? Thanks.
XML-link has no versioning machinery built in... this would be in the
territory of the WebDAV work, if anywhere. I think (but am not sure)
that there is some machinery for this in the URN work. Note that versioning
in the general case is a horribly complex problem and tends to have all
sorts of application-specific requirements, so I wouldn't bet too much
in finding a good general solution. -T.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From john at datachannel.com Tue Aug 5 19:11:44 1997
From: john at datachannel.com (John Tigue)
Date: Mon Jun 7 16:58:13 2004
Subject: Xapi-J: an architectural detail
References: <3.0.1.32.19970805074603.006bcb18@gorge.net>
Message-ID: <33E75F5F.CC7EC38E@datachannel.com>
Chris Lloyd wrote:
> akirkpatrick wrote:
> >I really like the combination of IContent and IContainer.
> >The only question I have is how an element can query
> >its context in an efficient way? For example, how can
> >I find the previous element without referring to the parent
> >container. Presumably then the parent would have to
> >enumerate all its children to find the previous content
> >to the element in question. Obviously a particular
> >application can record the previous element in a variable
> >but then you get to more complex contexts, like "what
> >is the previous of my parent".
> >
> This is where the next step is needed. Tree Iterators can provide
> efficient
> and well abstracted mechanisms for walking the XML tree. Everyone is
> still
> stuck on the schema part of Xpia-j and that is fine. After that is
> done
> then it's time to add classes specifically for navigation.
> Keep the schema simple. Don't add members for the previous child,
> etc.. It
> is unnecessary and complex to maintain.
I agree. I think we should follow the Visitor design pattern. Quoting
from Gamma's _Design_Patterns_: "Intent: Represent an operation to be
performed on the elements of an object structure. Visitor lets you
define a new operation without changing the classes of the elements on
which it operates." Here the operation is tree interation.
>
>
> Over the past 2 years, we have been developing an object database
> system
> for SGML. We have gone through the same thought processes as are going
> on
> with xapi-j right now. I think there are a few design considerations
> to
> keep in mind if you want to use iterator classes with the xapi-j
> schema and
> I think eventually you will.
>
> The idea of inheriting from IContainer is a good one. Polymorphism is
> very
> useful when it comes time to write navigation classes. A base class
> for all
> objects in the tree is very important!! We'll call this INode.
>
public interface INode {
// What do we put in here?
}
>
> Again I stress that every XML object in the tree should inherit from a
>
> single base class even if the base class does not provide any common
> interfaces to it's concrete classes. In this way, any XML object can
> be
> passed via a base class reference(Whoops, I almost said pointer). It
> is
> trivia to implement a fast, safe-casting mechanism that uses
> polymorphism
> for casting.
>
So the interfaces in Xapi-J would extend INode like this?
public interface INode {...}
public interface IContainer extends INode{...}
public interface IElement extends IContainer {...}
This way an IElement is also an INode so passing via base interface can
be done for any object in the model. We're still dealing purely with
interfaces so vendors are still free to implement their own base
classes. This also could be mapped to CORBA, DCOM, and others.
> This way, we can later add navigation classes that leverage the
> polymorphic
> nature of the XML tree.
>
--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue@datachannel.com
206-462-1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970805/0d9759e5/vcard.vcf
From eliot at isogen.com Tue Aug 5 20:10:29 1997
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun 7 16:58:13 2004
Subject: Linking and Query question
Message-ID: <3.0.32.19970805130657.00b1692c@swbell.net>
At 09:54 AM 8/5/97 -0700, Andrew Layman wrote:
>Can I create a link that, in effect, contains a query so that it
>references one document among a set? For example, if I know that several
>versions of a document exist, and I want to reference the latest
>version, but I'm willing to accept either of the two prior versions, can
>I express that? If so, how? Thanks.
If the reference to a document is via an entity reference, the query can be
part of the system ID for the document. As system IDs in XML are always
URLs, if you have a way of expressing the query in an URL, you can do it
that way. If not, then the short answer is "no" (unless there's some
aspect of URLs or TEI extended pointers I've overlooked, which it quite
possible).
In a general SGML system, there are three basic approaches:
1. Define your own application-specific addressing syntax and semantics and
use it, hoping tools will support it or providing your own support (because
the scope of use is totally within your control).
2. Use Formal System Identifiers and make the query part of an entity's
system ID.
3. Use query addressing and make the query part of a direct or indirect
address (that does not use a declared entity).
The only difference between these three approaches is that two and three
are done within the framework of standardized definitional mechanisms
defined by ISO/IEC 10744:1997 while one is not. In all three cases you
still have to implement support for the query and provide the necessary
integration with the tools you're using (browser to repository, editor to
repository, etc.).
The Formal System Identifier Definition Requirements (FSIDR) facility of
ISO/IEC 10744:1997 (Annex A.6, reviewable at
http://www.drmacro.com/hythtml/clause-A.6.html) provides a syntax for
associating repository-specific attributes with system IDs.
For example, say you have a repository with a "version" property for
storage objects. You can refer to this property by declaring the
repository as a "storage manager" and providing an attribute (or
attributes) for specifying the version you want, something like this:
][=]?)?[0-9]+(\.[0-9]+)?"
Prefixes for version number:
< Anything less than specified version
> Anything greater than specified version
<= Anything less than or equal to specified version
>= Anything greather than or equal to specified version
If no prefix specified, only specified version is used.
--
CDATA #IMPLIED -- Default: latest version --
>
Obviously, these declarations can be provided by the storage manager
provider and used by reference from documents--you wouldn't expect authors
to type these things themselves (or even necessarily be aware of their
presence or use).
You then invoke the storage manager by treating the notation name as an
element type name within the system ID:
1.2'>mydoc.xml" CDATA SGML >
As the semantics of the tags within a system ID are well defined by the
FSIDR, it is probably reasonable for XML systems to treat the tag name as a
repository notation name even when the formal declarations are not present.
If the storage manager name is well understood (e.g., "URL"), there's no
problem. It's probably also reasonable to assume that storage manager
names are generally unique and therefore processing can be associated with
the names directly (rather than by requiring a notation declaration with a
public ID). This is analogous to being able to map entities by entity name
within an SGML Open catalog.
A processor would provide a way to associate the storage manager notation
MyDocManager with that storage manager's API (i.e., the integrator of the
storage manager would register a DLL or DLL entry point with the notation's
public identifier). The processor would then pass the value of the version
attribute and the data following the MyDocManager start tag to the API.
If you're not addressing the document as an entity but using some other
query, I don't think XML Link provides a way to do this (because it doesn't
generalize the notion of addressing by query).
The HyTime architecture does generalize addressing by query such that you
can declare a query notation with whatever semantics you want and then use
that query. The only requirement is that the result of the query be a list
of nodes in groves. In DOM terms this would mean you get back objects
conforming to the DOM model, rather than the unparsed data of the document
addressed. (All addressing is in terms of the results of parsing, not the
unparsed source.)
For example, to create and use such a query, you could do something like this:
<-- Now declare an element type that uses this query notation for
addressing: -->
...
See My document...
A HyTime aware processor interprets the above as follows:
1. Sees that Doclink is a hyperlink. Looks for the required (by HyTime)
"anchrole" attribute, from which it will determine the names of the
attributes used to address the anchors (they are the same as the anchor
role names).
2. Sees that "refmark" is a self anchor, so no addressing attribute is
needed for it. Sees that second role is "document". Looks for attribute
named "document".
3. Finds attribute named "document". Looks for attribute named "loctype"
(location type) to see if a location type has been associated with this
attribute (without location type, the HyTime engine has no way of knowing
what form of addressing is being used [unless the attribute is declared as
IDREF(s) or ENTITY/ENTITIES]).
4. Finds a loctype attribute and sees that the document attribute is a
query location that uses the notation named "MyDocQuery"
5. Looks to see if a notation named MyDocQuery has been declared. It has.
6. Passes the value of the document attribute to the MyDocQuery API (again,
registered using whatever integration API the browser provides). The
processor (my document manager in this case), interprets the query and
provides a response.
7. Waits until it gets a response, which had better be a list of objects in
an object model it understands (e.g, grove nodes, DOM objects, etc.).
8. Assuming it gets a response, enables traversal to the returned objects.
XML Link removes the need for the above general processing by providing a
fixed set of query notations that XML Link recognizes (URLs and TEI
extended pointers). However, this limits your ability to do things these
two query notations don't provide for. Note also that the XML Link
specification can be defined in terms of the HyTime generalizations such
that any general-purpose HyTime engine can process XML Link documents (and
you would expect HyTime engines to have built-in support for XML Link so
that there would be no additional integration required to process XML Link
documents).
The HyTime mechanism has no "magic"--it just provides a framework within
which the integration you'd have to do in any case can be done. It simply
provides a way to name things (queries, storage managers) with
universally-unique names (public IDs) and associate these universal names
with local names (notation names). This framework standardizes the formal
declaration of what you're doing and (hopefully) makes the integration
mechanism consistent across tools, which shoudl make integration easier.
It doesn't remove the need for tools to be plugged together by humans
(either directly or through the definition of API standards like the DOM or
CORBA or ODBC).
Cheers,
Eliot
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From andrewl at microsoft.com Tue Aug 5 21:12:28 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:13 2004
Subject: Linking and Query question
Message-ID: <7BB61B44F197D011892800805FD4F7920133B7D4@RED-03-MSG.dns.microsoft.com>
Thanks. I like the power and exactness of the example you showed using
FSID. Now I need to find a way to integrate that with a URI scheme.
--Andrew Layman
AndrewL@microsoft.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From eliot at isogen.com Tue Aug 5 21:35:39 1997
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun 7 16:58:13 2004
Subject: Linking and Query question
Message-ID: <3.0.32.19970805142954.00b09c38@swbell.net>
At 12:11 PM 8/5/97 -0700, Andrew Layman wrote:
>Thanks. I like the power and exactness of the example you showed using
>FSID. Now I need to find a way to integrate that with a URI scheme.
Cool. Let me know if I can be of assistance in any way.
Cheers,
Eliot
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From ricko at allette.com.au Tue Aug 5 22:39:34 1997
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 16:58:13 2004
Subject: XML and whitespace: lets just dump CR and LF!
Message-ID: <199708052044.GAA01690@jawa.chilli.net.au>
> From: Tim Bray
> Heh-heh. If you go look in the proceedings of the 1988 Usenix conference,
> you'll find a paper I wrote, on the Oxford English Dictionary project,
> which has a section entitled
>
> '\n' Considered Harmful
>
> I'd love to lose the record-end silliness. Trouble is, we're stuck with
> it until we have better editing tools. -T.
I'm not saying to ban the characters, merely to say give them no significance
for an application. So we can still use our existing editing tools.
For example, using vi or sed to add the unambiguous newline to an existing file,
which will be stuck in an HTML-like
, it is merely a rule like
1,$s/$/\ /
which is trivial.
We can do this only because we are using ISO 10646 as the document character
set: since we have the chance to clear up the mess with a simple convention,
why not take it!
Rick Jelliffe
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From clloyd at gorge.net Wed Aug 6 00:07:44 1997
From: clloyd at gorge.net (Chris Lloyd)
Date: Mon Jun 7 16:58:13 2004
Subject: Xapi-J: an architectural detail
Message-ID: <3.0.1.32.19970805150432.006ba560@gorge.net>
>John Tigue wrote:
>>
>>I agree. I think we should follow the Visitor design pattern. Quoting
>>from Gamma's _Design_Patterns_: "Intent: Represent an operation to be
>>performed on the elements of an object structure. Visitor lets you
>>define a new operation without changing the classes of the elements on
>>which it operates." Here the operation is tree interation.
>
Yes, Our whole system is based on "Design Patterns". We use the visitor
pattern for formatting output and for operations where we walk a subtree
from stem to stern. They are useful and easy to implement. Visitors are
good for moving an operation outside a class. They are not so good for
defining and extending complex walking tasks.
We find it necessary to have iterators for complex walking tasks. You can
let an iterator drive a visitor as well. We are doing very complex queries
right now using iterators, algorithmns, functions, and operators. The last
three patterns are borrowed from STL. The problem with the last three
patterns for Java is that they are template driven. A very complex tree
walking query/algorithmn can be formulated in a single line of C++. I'm
sure they could be adapted to Java.
We are dealing with tree versioning as well, so we have trees within trees.
You just can't expect to walk this stuff without some well abstracted
navigation patterns.
>I wrote:
>> The idea of inheriting from IContainer is a good one. Polymorphism is
>> very
>> useful when it comes time to write navigation classes. A base class
>> for all
>> objects in the tree is very important!! We'll call this INode.
>>
>
>public interface INode {
> // What do we put in here?
> }
>
It is not necessary for anything to be in the base class. It is just
necessary for there to be one.
For example: An Iterator has a very simple interface
public interface ITreeIterator
{
ITreeIterator(INode, ICursor iCursor, INodeIterFactory iFactory);
bool next(); // walk to the next node
INode current(); // return the current node
long GetIterLevel(); // return how many tags deep we are from starting
position
}
We construct the iterator with a current node which can be the document
root or any object in the tree. We use a cursor which externalizes the
walking algorithmn(forward, backward, follow links) and we use a Factory
which provides the algorithmns for walking each object type in the tree.
This iterator will return different objects in the tree or maybe even walk
the tree differently depending on the factory and cursor that it is
constructed with.
This iterator will not work without a common base class because the
iterator knows NOTHING about the types of objects in the tree. It only
knows what an INode is.
>So the interfaces in Xapi-J would extend INode like this?
>
>public interface INode {...}
>
>public interface IContainer extends INode{...}
>
>public interface IElement extends IContainer {...}
>
>This way an IElement is also an INode so passing via base interface can
>be done for any object in the model. We're still dealing purely with
>interfaces so vendors are still free to implement their own base
>classes. This also could be mapped to CORBA, DCOM, and others.
YES!
Chris Lloyd
POET Software
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From h.rzepa at ic.ac.uk Wed Aug 6 09:46:07 1997
From: h.rzepa at ic.ac.uk (Rzepa, Henry)
Date: Mon Jun 7 16:58:13 2004
Subject: XML-DEV Digest
Message-ID:
A number of people have asked for a digest of this list. I forwarded this
request to our postmaster. As soon as it is actioned, I will let this list know
the details.
Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY;
mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804.
URL: http://www.ch.ic.ac.uk/rzepa/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From Peter at ursus.demon.co.uk Wed Aug 6 17:19:29 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:13 2004
Subject: Xapi-J: an architectural detail
Message-ID: <9160@ursus.demon.co.uk>
In message <33E75F5F.CC7EC38E@datachannel.com> john@datachannel.com (John Tigue) writes:
Firstly many thanks to John for driving this forward and for the positive replies
from several others. let's make sure that we get closure on this fairly shortly
as we don't want to fall back to where we were 4-5 months ago with a lot of
enthusiasm and no final outcome.
I know we are all doing this on a voluntary basis, but if we get it right this
time we save a lot of problems later. I have put my JUMBO development on hold
because I really want to get it on top of a decent architecture. We need to
know precisely what an Element, Node, etc. are :-)
I get the impression from John and others that it is possible to create an
API which does not necessarily suport the property set today, but is capable
of doing it in the future without rewriting. If so, then perhaps John and
others could suggest where they intend to freeze the current API at. If we don't
set some limits now, there is the danger that we try to be too ambitious.
As soon as an API is established, a benefit will be that we can start to think
about what other features of XML processing need to be covered in a generic
manner. I found that quite of lot of JUMBO implementation was generic
(e.g. checking semantic validity, 'inheritance/default' implementation, etc.
which is not trivial and should be isolated as far as possible from applications.
>
> Chris Lloyd wrote:
[...]
> > This is where the next step is needed. Tree Iterators can provide
> > efficient
> > and well abstracted mechanisms for walking the XML tree. Everyone is
> > still
> > stuck on the schema part of Xpia-j and that is fine. After that is
> > done
> > then it's time to add classes specifically for navigation.
>
> > Keep the schema simple. Don't add members for the previous child,
> > etc.. It
> > is unnecessary and complex to maintain.
I agree with this - it should be possible to add these in at a later stage
(e.g. by subclassing in Java). I have a lot of stuff in JUMBO that implements
treewalking (e.g. TEI Xptrs) and even tree-editing, and my Tree/Node classes
can have up to 100 methods each. We want to avoid this at this stage :-)
>
> I agree. I think we should follow the Visitor design pattern. Quoting
> from Gamma's _Design_Patterns_: "Intent: Represent an operation to be
> performed on the elements of an object structure. Visitor lets you
> define a new operation without changing the classes of the elements on
> which it operates." Here the operation is tree interation.
>
> >
> >
> > Over the past 2 years, we have been developing an object database
> > system
> > for SGML. We have gone through the same thought processes as are going
> > on
> > with xapi-j right now. I think there are a few design considerations
> > to
> > keep in mind if you want to use iterator classes with the xapi-j
> > schema and
> > I think eventually you will.
> >
> > The idea of inheriting from IContainer is a good one. Polymorphism is
> > very
> > useful when it comes time to write navigation classes. A base class
> > for all
> > objects in the tree is very important!! We'll call this INode.
> >
I tend to support this. It makes general management such as editing and display
easier, even if the Node objects are not of the same class.
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From Peter at ursus.demon.co.uk Wed Aug 6 17:19:57 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:14 2004
Subject: Specification Questions
Message-ID: <9162@ursus.demon.co.uk>
In message <199708050949.KAA07792@andromeda.ndirect.co.uk> "Neil Bradley" writes:
>
>
> Reply-to: Peter@ursus.demon.co.uk (Peter Murray-Rust)
>
> > Some additional - hopefully constructive - thoughts on whitespace.
> >
> > The XML-lang spec does not ( and I suspect will not) give detailed guidance
> > on how whitespace will be managed. My impression is that it is up to
> > implementers and/or groups like this to come up with particular solutions.
> > My worry is that these will be inconsistent and not inter-operable.
>
> I agree totally. This was my original concern.
>
> > ***
> > Therefore I propose that those on XML-DEV who care about this problem come
> > up with some guidelines for implementers.
> > ***
>
> I very much hope this happens.
>
[...]
>
> I think all applications should be expected to either or both
> characters in sequence as a line end signal, so that platform
> dependancies can be eliminated. If there is no good reason to omit
> this taks from the XML-processor itself, I think it should be done
> there.
>
>
[...]
>
> I believe so. In addition, can we not put 'XML-SPACE
> (PRESERVE|IMPLIED) "PRESERVE" in an attribute declaration for an
^^^^^^^
I think you meant DEFAULT - #IMPLIED is when no value is given.
> element which will always have reserved content. It is common
> practice for a DTD to have some kind of pre-formatted element, such
> as HTML's '
'.
>
>
> > If so, we can propose that the DEFAULT mode for any whitespace processing is
> > something along the lines (similar to HTML?). Within an element with
> > XML-SPACE="DEFAULT"
> >
>
> > All whitespace sequences are mapped into a single space character.
> Agreed.
>
> > All whitespace pseudo-elements are ignored (i.e. whitespace between markup)
>
> Ummm. what about 'the bolditalic styles...'?
>
> > All leading and trailing whitespace in #PCDATA is ignored.
>
> I think all applications should remove leading and trailing CR and LF
> characters in a mixed content element. But not SP or HT, as this would
> be undesirable in the following fragment:
>
> A bold word.
>
> Although an unusual layout, some people may use it, and it would be
> unfortunate if it resulted in 'Aboldword'.
>
OK - I had overlooked this.
Taking account of other posts on this subject here and elsewhere, there seems to
be a positive view that a set of Guidelines/Best Practice/Gerally Agreed
Conventions should be developed, and that XML-DEV is probably the right place.
It's also clear that the more of this that can be done before the XMLProcessor
output gets to the *specific* application - e.g. a browser or transformer - the
better. We seem to be looking at a filter or layer immediately after/on_top_of
the XMLProcessor. At the ESIS stream level we could have:
Document ->[Parser] -> ESIS -> [XMLWhitespace] -> NewESIS -> [Application]
and at the API level something that either sits on top of the EventStream or
the final TreeFactory (or whatever it's called).
(There is a difficulty in filtering any document, in that XPtrs in XML-LINK
would appear to have to operate on the unfiltered document (although this is
not specifically stated, it's implied). So it might have to be that the
stream or tree contained 'significant' and 'non-significant' whitespace, and
that the application would have to be able to recognise the flag. All Xptr
activity has to take place on *all* whitespace (although I don't think this
is pretty).
The current switch PRESERVE is clear (everything goes through). It would go
against the spec if it didn't do this. That means (I suppose) that CR+LF is
different from LF - that's the price paid for PRESERVE. The other option DEFAULT
cannot map onto a set of actions that we all agree for all documents. Therefore
we have to give DEFAULT some hints at the *document* level - presumably through
PIs.
Can we propose, therefore. a set of PIs that would control whitespace
processing? I would hope that we could keep this to a very small number
(ca. 3-4). Is it too simple to suggest that there are two types of markup
(STRUCTURE and TEXT) that need to normalise whitespace? the former would
deal with things like:
where the author did not intend there to be any whitespace, and the second
would deal with
This is a
long space in a paragraph.
where all whitespace would be normalised to a single space as in HTML?
Where a document contained both, the author could use a PI to switch between
them.
If we could come up with a very simple set of options, it might make it
sufficiently simple that a standard filter could be devised, or the application
programmer had a much simpler strategy. Is consensus possible?
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From Peter at ursus.demon.co.uk Wed Aug 6 17:20:08 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:14 2004
Subject: XML and whitespace: lets just dump CR and LF!
Message-ID: <9163@ursus.demon.co.uk>
In message <199708051317.XAA23619@jawa.chilli.net.au> "Rick Jelliffe" writes:
[...]
>
> I suggest that the following approach should be taken. (I think it is the only
> realistic solution, especially if we assume that 1)
> data is usually generated by applications,
Although this will be partly true, I think we still have to expect people
to use text editors for a year or two yet :-). [It's how I create most of
my XML at present :-)].
> 2) humans only check and tweak data;
Yes. XML must certainly be tweakable. So it mustn't have to have lines 1000
chars long :-)
> 3) we want operating system
> and character set independence,
critical :-)
4) line-breaking is generally done by clients
> ...so CR/LF is basically a convenience for fitting data into editors,
> not for the purposes of output.)
Yes.
>
> **A) XML applications should ignore *ALL* CR and LF as a bad joke. They should
> be entirely there for formatting the raw text into nice, eye-sized records.
> So CR and LF should never be converted to spaces. (This approach was the
> one taken by Interleaf, and I have come to appreciate it.) If you need a
> space, then start the new line with it! (Ending the previous line is difficult
> to see.)
Appeals to me :-)
>
> **B) XML applications should mandate the use of the unambiguous Unicode characters
> -- LINE SEPARATOR
> -- PARAGRAPH SEPARATOR
>
This makes sense unless someone finds a flaw in it...
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From sarah at attd.com Wed Aug 6 21:55:13 1997
From: sarah at attd.com (Sarah Slocombe)
Date: Mon Jun 7 16:58:14 2004
Subject: Xapi-J: an architectural detail
Message-ID: <3.0.32.19970806155554.006b6f00@mail.lglobal.com>
Greetings!
I've been following this thread with great interest.
I'm trying to piece together the suggestions so far but
I wonder if I've muddled it already. Perhaps I should just
wait a bit longer but things are really starting to get
exciting now!
As I understand it, we've got:
public interface INode{
public INode getParent();
public void setParent(INode aContainer);
}
(Or is INode ONLY so things have a common base class/
interface, and shouldn't have any methods? Or does an
IContainer never need to deal with parents? Or ought even
parent stuff to be handled by iterators?)
public interface IContainer extends INode{
public Enumeration getContents();
public void insertContent(IContent aContent,
IContent preceedingContent);
public void appendContent(IContent aContent);
public void removeContent(IContent aContent);
}
public interface IContent extends INode{
public String getData();
}
public interface IElement extends IContent, IContainer{
public String getType();
public void setType(String aType);
public void addAttribute(String name, String value);
public void removeAttribute(String name);
public IAttribute getAttribute(String attributeName);
public java.util.Enumeration getAttributes();
}
So far so good? Now what about IAttribute? John Tigue's
shown:
public interface IAttribute{
public String getName();
public void setName(String aName);
public String getValue();
public void setValue();
}
Ought this to inherit from IContent? Chris Lloyd spoke of
IContainer vs. IProperty -- are IContent and IProperty the
same thing?
Thanks for any help.
Sarah Slocombe
sarah@attd.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From john at datachannel.com Wed Aug 6 22:49:28 1997
From: john at datachannel.com (John Tigue)
Date: Mon Jun 7 16:58:14 2004
Subject: Xapi-J: an architectural detail
References: <3.0.32.19970806155554.006b6f00@mail.lglobal.com>
Message-ID: <33E8E3E4.AAA99E5@datachannel.com>
Sarah Slocombe wrote:
>
> So far so good? Now what about IAttribute? John Tigue's
> shown:
>
> public interface IAttribute{
> public String getName();
> public void setName(String aName);
> public String getValue();
> public void setValue();
> }
>
> Ought this to inherit from IContent? Chris Lloyd spoke of
> IContainer vs. IProperty -- are IContent and IProperty the
> same thing?
>
IContent is for things in things so I think IAttribute would extend
INode and maybe an IProperty but not IContent as it was initially
designed. We haven't nailed down which interfaces are in Xapi-J. I think
Chris was saying that IProperty is for leaves in the parse tree. I've
been maintaining a site which discusses the Xapi-J interfaces at
http://www.datachannel.com/ChannelWorld/xml/dev. You can find the other
Xapi-J interfaces there.
As for stopping at some point and labeling what we have as Xapi-J 1.0, I
think we are very close to a point where we can do that. The real work
is having XML processor providers implementing Xapi-J. I have a
functional XML processor which complies to Xapi-J which I've been using
to test the concepts. It doesn't reflect the latest stuff like INode.
I'll rev the site and the example processor this weekend.
--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue@datachannel.com
206-462-1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970806/0f3d455d/vcard.vcf
From andrewl at microsoft.com Thu Aug 7 00:16:20 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:14 2004
Subject: XML-Link: Relative URL expansion
Message-ID: <7BB61B44F197D011892800805FD4F7920133B7FF@RED-03-MSG.dns.microsoft.com>
If an XML-Link element has a relative URL in its href attribute, what is
used as the base for resolving the URL? I presume the URL of the
containing document. Is this correct?
--Andrew Layman
AndrewL@microsoft.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From tbray at textuality.com Thu Aug 7 00:26:59 1997
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 16:58:14 2004
Subject: XML-Link: Relative URL expansion
Message-ID: <3.0.32.19970806152015.00830410@pop.intergate.bc.ca>
At 03:15 PM 06/08/97 -0700, Andrew Layman wrote:
>If an XML-Link element has a relative URL in its href attribute, what is
>used as the base for resolving the URL? I presume the URL of the
>containing document. Is this correct?
More properly "containing resource", but yes. Check the XML spec, section
4.3.2, for some more details. In this connection I'd also recommend a look
at RFC 1808. -T.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From andrewl at microsoft.com Thu Aug 7 00:54:02 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:14 2004
Subject: FW: First Draft of RDF, differences from my notes.
Message-ID: <7BB61B44F197D011892800805FD4F7920133B80B@RED-03-MSG.dns.microsoft.com>
After reading the RDF paper, I posted the following message to the RDF
working group. Since the RDF paper is now posted to the XML dev mailing
list, these comments are relevant in the new context.
--Andrew Layman
AndrewL@microsoft.com
> -----Original Message-----
> From: Andrew Layman
> Sent: Friday, August 01, 1997 4:24 PM
> To: w3c-labels-wg@w3.org; w3c-dsig-collect@w3.org
> Subject: First Draft of RDF, differences from my notes.
>
> Thank you for the early draft of the paper. In reading it over, I've
> found a number of points that differ from my recollection of our
> Boston meeting. Perhaps my notes and memory are wrong on some of these
> points (in which case I welcome correction) but it also appears that
> some new features have crept into the document:
>
> 2. We only agreed on ablocks describing single resources. I
> remember discussing having an RDF assertion block describe
> characteristics of more than one resource, but concluding that this is
> a difficult problem with great risk of user confusion. (I'm not
> opposed to solving this problem; just want to note that we did not
> solve it but left it for the future.)
>
> 2.4 I don't remember us ever finding a satisfactory way for the
> ablock to actually contain its target resource (because the
> subelements of an ablock are interpreted as properties of the ablock's
> target).
>
> 2. We discussed the need for a small set of base data types, which
> I believe were strings, numbers and dates/times. We also talked at
> length about the need to distinguish between a base semantic type such
> as date and a particular format such as ISO8061. The sentance
> beginning "The domain of property values..." does not reflect dates or
> the semantic/format distinction.
>
> 3. I don't remember agreement on refTypeAttr. Did we but I don't
> have it in my notes?
>
> 3. We most definitely did not agree that the first namespace
> element sets a default namespace! We did agree, tentatively, that we
> might make the "as" attribute optional, where its omission could
> signal that it was to be the default namespace for its containing
> element (with the caveat that this needs more thought). We also
> discussed that a namespace attribute on the containing element might
> be a better way to achieve the same effect.
>
> 3. I remember discussing listItem, but don't remember ever nailing
> it down precisely or agreeing on it.
>
> Example 5.1.1. This simply needs to be clarified. I think what
> is meant is that an ablock with no href has as its implied target the
> entirety of the enclosing document.
>
> 5.2.3 The note at the bottom makes the assertion that a downlevel
> application can blindly concatenate together elements it does not
> understand. My recollection is that we discussed this, concluded that
> such a policy is dangerous and presumes to dictate processing. We did
> agree to investigate adding some standard attribute that might signal
> when such a policy is reasonable. We identified three values for such
> an attribute: (a) ignore the unknown element, (b) ignore the unknown
> tag, (c) application cannot process this element or any peer.
>
> I don't mean these comments to be interpreted as disagreements with
> any aspect of the RDF design, but rather as a report on differences
> between my notes and the current paper.
>
> --Andrew Layman
> AndrewL@microsoft.com
>
> -----Original Message-----
> From: Ralph R. Swick [SMTP:swick@w3.org]
> Sent: Friday, August 01, 1997 9:49 AM
> To: w3c-labels-wg@w3.org; w3c-dsig-collect@w3.org
> Subject: First draft of RDF specification for review
>
> The first draft of the Resource Description Framework Model and Syntax
> specification (Lassila & Swick, eds.) is now ready for your review and
> comment.
>
> http://www.w3.org/Member/9708/WD-rdf-syntax-970801.html
>
> I would like to ask this working group's permission to distribute
> this draft to w3c-xml-sig. xml-sig is the forum where technical
> discussions of XML are ocurring and they particularly need to see
> our requirements for the namespace tag. The only reason I ask your
> consent is that while xml-sig is a W3C Members forum, it has quite
> a few non-Member invited experts. I will distribute this draft to
> that list at 1600UTC on Monday, August 5 unless I hear serious
> objections before then.
>
> Thanks to all who have contributed thus far, and to each of you who
> will take the time to review and make suggestions for improvement.
>
> -Ralph and Ora
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From andrewl at microsoft.com Thu Aug 7 00:54:41 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:14 2004
Subject: RDF Specification: Ambiguity of the ABLOCK
Message-ID: <7BB61B44F197D011892800805FD4F7920133B80C@RED-03-MSG.dns.microsoft.com>
--Andrew Layman
AndrewL@microsoft.com
> -----Original Message-----
> From: Andrew Layman
> Sent: Friday, August 01, 1997 4:55 PM
> To: w3c-labels-wg@w3.org; w3c-dsig-collect@w3.org
> Subject: RE: First draft of RDF specification for review
>
> The example shown in 5.1.4 shows an interesting aspect of RDF:
>
>
>
> 1
> 45
> 70
>
>
>
> Color is a property with three sub-elements. However, it is not
> written that way. Instead it is shown containing an ablock, which then
> has three sub-elements.
>
> What is the target of this ablock? Section 5.1.1 implies that an
> ablock without an href has as its target the containing document.
> Here, the rule seems to be that the target is the immediate parent.
>
> Why do we need this ablock? Why do we not just have a color that
> itself has three sub-elements, as in
>
>
> 1
> 45
> 70
>
>
> I think the reason we don't is that the RDF rule about properties is
> that they must be binary. That is, the target of the color property
> must be a single object. In actuality here, we have what amounts to a
> quaternary relation, so we have interposed this "ablock" element in
> order to reify the quaternary relation.
>
> I don't think this is the same kind of ablock at all as used in 5.1.1.
> In fact, I don't think that "ablock" is the right element. The literal
> interpretation of 5.1.4 is that the target of the color relation is a
> typeless thing with three properties. Should not the target be a
> color? As in
>
>
>
> 1
> 45
> 70
>
>
>
> We could also reach this conclusion by thinking about the colorHSV as
> a datatype describing how to interpret its subelements to produce a
> color. (This point has implications for general thinking about data
> types.)
>
> --Andrew Layman
> AndrewL@microsoft.com
>
> -----Original Message-----
> From: Ralph R. Swick [SMTP:swick@w3.org]
> Sent: Friday, August 01, 1997 9:49 AM
> To: w3c-labels-wg@w3.org; w3c-dsig-collect@w3.org
> Subject: First draft of RDF specification for review
>
> The first draft of the Resource Description Framework Model and Syntax
> specification (Lassila & Swick, eds.) is now ready for your review and
> comment.
>
> http://www.w3.org/Member/9708/WD-rdf-syntax-970801.html
>
> I would like to ask this working group's permission to distribute
> this draft to w3c-xml-sig. xml-sig is the forum where technical
> discussions of XML are ocurring and they particularly need to see
> our requirements for the namespace tag. The only reason I ask your
> consent is that while xml-sig is a W3C Members forum, it has quite
> a few non-Member invited experts. I will distribute this draft to
> that list at 1600UTC on Monday, August 5 unless I hear serious
> objections before then.
>
> Thanks to all who have contributed thus far, and to each of you who
> will take the time to review and make suggestions for improvement.
>
> -Ralph and Ora
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From andrewl at microsoft.com Thu Aug 7 00:57:41 1997
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 16:58:14 2004
Subject: FW: content: sequence?
Message-ID: <7BB61B44F197D011892800805FD4F7920133B80D@RED-03-MSG.dns.microsoft.com>
The following is a message to the RDF working group regarding sequence
in RDF. This led to some subsequent discussion in which I argued that
if sequence is a generally useful concept, 3a is the best answer. We
also discussed the relative merits of indicating sequence on the
containing element vs. the contained.
--Andrew Layman
AndrewL@microsoft.com
> -----Original Message-----
> From: Andrew Layman
> Sent: Monday, August 04, 1997 2:55 PM
> To: w3c-labels-wg@w3.org; w3c-dsig-collect@w3.org
> Subject: RE: content: sequence?
>
> We did not reach agreement on how best to handle sequence in Boston,
> though we did agree that there are times in RDF when sequence is
> significant and other times when it is not. We discussed the
> possibility of having an attribute on an element signalling to an
> application when it could ignore sequence. This was generally agreed
> to as a direction, but we did not agree on what the appropriate
> default should be.
>
> There were three approaches discussed:
>
> 1. a. Sequences are always important on some (tbd) elements
> (e.g. "list") and never on others.
> b. Sequences are not important on some (tbd) elements (e.g.
> "ablock"), but are significant on all others.
>
> 2. Sequence-significance could be indicated by an attribute,
> required on elements defined by RDF, and presumably unavailable on
> other elements.
>
> 3. Sequence-significance could be indicated by an attribute that
> can be used on any element. If omitted, and if no default was given in
> a schema, then
> a. The application should follow the XML precedent
> of treating sequence as significant (after all, it might be).
> b. The application should treat sequence as
> insignificant (after all, that takes less processing).
>
> Separately, we briefly discussed whether sequence-significance should
> be lexically inherited, but this dissolved into the general difficulty
> of lexical inheritance.
>
> By my calculation, the only options fully compatible with XML without
> implying any sort of contextual processing or lexical inheritance are
> 1a, 2 and 3a.
>
> --Andrew Layman
> AndrewL@microsoft.com
>
> -----Original Message-----
> From: Tim Bray [SMTP:tbray@textuality.com]
> Sent: Saturday, August 02, 1997 12:15 PM
> To: w3c-labels-wg@w3.org; w3c-dsig-collect@w3.org
> Subject: content: sequence?
>
> The draft does not, unless, I missed it, allow for sequence in the RDF
> model. This is going to be widely required in all sorts of classes of
> metadata (examples on request). I don't think RDF 1.0 is worthwhile
> without
> sequence.
>
> Suggestion: RDF already has a list primitive. If I say
>
>
>
> PanoramaNavigatorNotepad
>
>
>
>
>
> then I think we have a sequenced property value. Does this work?
>
> Cheers, Tim Bray
> tbray@textuality.com http://www.textuality.com/ +1-604-708-9592
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From ricko at allette.com.au Thu Aug 7 18:46:54 1997
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 16:58:14 2004
Subject: XML and whitespace: lets just dump CR and LF!
Message-ID: <199708071652.CAA06410@jawa.chilli.net.au>
> From: Eric Baatz
> > XML applications should ignore *ALL* CR and LF as a bad joke.
>
> That doesn't seem reasonable from my point of view, although an option to do
> so might be reasonable. For example, my XML application, which reads text
> and speaks it, is likely to be fed existing text that is only lightly marked
> up with XML and that uses CR/LF (or newlines) and whitespace to convey
> important information. My application needs to see that information to
> operate in an acceptable manner. For example, input could be narrative
> paragraphs denoted by adjacent newlines (or CR/LF's), poetry (lots of
> prosodic information is in the the breaks and whitespace), or columns of
> text (such as newspapers) and numbers (such as spreadsheets) that have not
> been reduced to a single logical flow of characters.
Under the current proposals, white-space is preserved or defaulted. (This
relates to labelling data for applications, not on how the application
presents it.) So there is no way to indicate whether newlines are hard returns
or soft returns.
I think this hearkens back to XML last year, when the idea was around that
XML without declarations would be mainly used for closed-systems, where the
recieving end had been built with a specific DTD in mind.
Now it seems that this is not a big factor in the WG's mind, as the
XML-ATTRIBUTE discussion show: the WG wants to support systems that work
with many DTDs, even if they are not declared. (I, of course, think this
is a mistaken change in direction for XML, but I bow to collective wisdom.)
Under a closed-system approach, it made sense to say "default" or "preserve",
since "default" and "preserve" might have some determinate meaning. Under
the new all-singing-all-dancing direction for XML, I think they make little sense.
If XML-SPACE is just "preserve" or "default", then document instance's
newline coventions must be tailored for each application. But what if we
are processing against an architectural form? Then every instance must
use the the newline conventions belonging to the meta-Document Type Definition.
And what if you have different AFs active at different parts of the document,
or even applicable concurrently on some elements? Then all the meta-DTD's
newline conventions must match, or you must adopt different conventions
at different parts of the document.
A hard return should be explicitly marked up: whether it is an attribute or
a PI or a element or , it should not be stuck outside the
element in CSS or DSSSL--it is part of the data, not an artifact of formatting.
(I suppose that the Remappers will think it desirable to define a new standard
XML attribute that specifies which convention you use (PI, attribute, ,
character reference, entity reference) to signify hard returns, and then
provide other attributes to let us cope with existing DTDs that have churlishly
adopted their own, prior, conventions. But I think it is simpler to merely
say "The only way to signify hard returns in XML is " )
If you have gotten rid of hard returns, then next we need to sort out
newlines that are soft returns in data from newlines that are in
(or "attributable to") markup or element content. For this distinction,
XML-SPACE may be good enough, in a brutish way. But I think that the
Interleaf option, of making newlines not significant for presentation, is
superior, for the reasons given before. I would also add another: it
may simplify indexing into character strings--if you decide "CR and LF
are not significant for presentation or indexing" then you get rid of
the problem of documents needing to tell you which newline conventions they
have adopted: you don't care, and the users are free to translate between
different conventions without impacting indexes into documents (all other
things being equal).
Rick Jelliffe
P.S. An Omnimark program to markup an existing well-formed HTML-in-XML
document would be merely to add to a XML normaliser:
TRANSLATE "%n" WHEN ANCESTOR IS PRE
OUTPUT " %n"
TRANSLATE "%n"
OUTPUT "%n "
This does not seem too complex at all.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From shawnhsu at ARC.unm.EDU Thu Aug 7 21:53:23 1997
From: shawnhsu at ARC.unm.EDU (Xu, Xiang)
Date: Mon Jun 7 16:58:14 2004
Subject: Publisher Seeking XML Authors
Message-ID: <3.0.1.32.19970807135137.006adf58@arc.unm.edu>
Hi:
We are a computer book publishing company by the name of Bigi International
USA. Asking who will be interested in writing books about XML. Please reply
to us as soon as possible.
Thanks
Best Regards
-Xiang Xu
=================================
Xu, Xiang
Bigi International USA Inc.
email: shawnhsu@arc.unm.edu
http://www.bigiintl.com
Tel:(505)830-1443(O), (505)232-8223(H)
FAX:(505)830-1448
2501 San Pedro Blvd., NE, Suite 208
Albuquerque, NM 87110, USA
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From john at datachannel.com Fri Aug 8 02:32:08 1997
From: john at datachannel.com (John Tigue)
Date: Mon Jun 7 16:58:15 2004
Subject: DOM and Xapi-J
Message-ID: <33EA6992.B6615F6D@datachannel.com>
Some questions have arisen as to the possibility of conflicting overlap
between the DOM and Xapi-J. For those areas where they do overlap, I see
Xapi-J as eventually being a proper subset of the DOM. For example:
The DOM is language independent. Xapi-J is Java only.
The DOM is platform independent. Xapi-J is for the Java platform only.
Xapi-J is designed to be a stylistically consistent extention to the JDK
which embeds it even further into Java e.g. see the recent thread
entitled "Xapi-J: an architectural detail"
The DOM covers HTML and XML. Xapi-J only covers XML.
Eventually, I would think that Xapi-J compliant processors would be seen
as having a DOM-compliant object model of an XML document because they
will eventually use the DOM's Java language bindings exactly. There are
also many other features of the DOM requirements which are not reflected
in Xapi-J. The parts of Xapi-J related to how a developer instantiates a
processor and optionally get ESIS parse events out of one of these
JavaBeans does not overlap with the DOM work.
I think we can declare Xapi-J 1.0 complete at any time now. When the DOM
is done I think Xapi-J should be reved to be a direct subset of the
DOM's object model using the DOM's object model and method signatures
exactly. That is the only part I see where there is overlap and it would
be a shame to have two very similar but different object models of an
XML document. The original goal of Xapi-J was to come up with a unified
model/api for Java developers who are using/writing XML processors. To
not reflect the work of the DOM WG would defeat the whole idea.
--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue@datachannel.com
206-462-1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970808/3df6ada0/vcard.vcf
From Peter at ursus.demon.co.uk Fri Aug 8 10:06:49 1997
From: Peter at ursus.demon.co.uk (Peter Murray-Rust)
Date: Mon Jun 7 16:58:15 2004
Subject: DOM and Xapi-J
Message-ID: <9260@ursus.demon.co.uk>
In message <33EA6992.B6615F6D@datachannel.com> john@datachannel.com (John Tigue) writes:
[...]
>
> I think we can declare Xapi-J 1.0 complete at any time now. When the DOM
I think this is a great achievement, and I'd like to thank John both for the
API and for continuing the momentum. Also thanks to everyone who has
contributed ideas.
This group is not, of course, part of the formal process of XML under W3C, but
I believe that anyone involved in XML development will take Xapi-J as a central
reference. I would suggest that those who have pages publicising XML resources
should include this. John - is there now a definitive URL that should be used?
> is done I think Xapi-J should be reved to be a direct subset of the
> DOM's object model using the DOM's object model and method signatures
> exactly. That is the only part I see where there is overlap and it would
> be a shame to have two very similar but different object models of an
> XML document. The original goal of Xapi-J was to come up with a unified
> model/api for Java developers who are using/writing XML processors. To
> not reflect the work of the DOM WG would defeat the whole idea.
It seems clear to me that there will continue to be revisions to many parts
of XML (we do not yet have a definitive version). So revision of Xapi-J to
be consistent with DOM will be one of several such adjustments or extensions.
I hope that other reference documents will come out of public debate on XML-DEV.
I think there are going to be a large number of problems which are not defined
by the spec and which are not felt appropriate for discussion by the WG (the
formal W3C body) or the SIG (now not public). From time to time it is
suggested that 'this is an implementation problem, - perhaps XML-DEV would be
appropriate?'
Some of us are concerned that uncoordinated (though well-meant) implementation
of XML applications and tools will create a range of inconsistent approaches.
At present XML-DEV is the only forum for discussing these and I think we have
a critical role here. Obviously any contributions are voluntary, not part of the
W3C process, but if we continue to come up with well-thought out documents or
proposals they should have an important role.
Some areas where I think guidance for implementers is critically needed NOW
(in rough priority) are:
- whitespace processing
- error processing
- treatment of defaults and inheritance
- interpretation of XML-LINK constructs
Volunteers? Should we adopt any sort of informal process? Thoughts? :-) Perhaps
those who are able to be present at XML-DEV day might wish to discuss this?
P.
--
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From Alain.Michard at inria.fr Fri Aug 8 13:57:44 1997
From: Alain.Michard at inria.fr (Alain Michard)
Date: Mon Jun 7 16:58:15 2004
Subject: FPIs as locators in XML-links ?
Message-ID: <199708081157.NAA21705@yana.inria.fr>
I may miss something (and in that case thanks for the help!) , but I
feel that the current specification of locator in XML-LINK don't open an
easy way to avoid including URLs in XML documents.
It is true that a URL can be considered as a unique id of one physical copy
of a resource, but this id is transient : machines may be changed, and
"publishers" (any entity putting content on the Web) may decide to migrate a
document repository from one place to another.
If locators in XML-LINKS are URLs, this implies that in case of change of
URL, many authors
-a- should ideally be notified in some way of the change if it is relevant
for them (ie: if they have in their own documents links pointing to
resources which have changed of URL)
-b- have to retrieve all the document they have published which contain a
link to the modified URL;
-c- have to edit all these documents.
That's in fact exactly the situation with the HTML-based Web.
I feel that the SGML practice to use Public Identifiers and to store
mappings of PUBLIC identifiers to SYSTEM identifiers in a Catalogue file
facilitates greatly the management of large collection of documents:
- a "publisher" may distribute updates of his public catalogue to the
community with which he shares a number of resources;
- the catalogue is the only file you need to edit when any Public ID gets
associated to a new physical resource;
- in case of mirror copies of Web sites, the catalogue may be an easy mean
to impose to your browser to look for a given document at a given site,
without having to specify it at each traversal of a link;
Moreover, including URLs in XML documents appears contradictory to the
general phylosophy of SGML, which I guess could be resumed as "Ensure
long-term life of documents".
I would be very interested to read some comments from SGML experts on the
list, to help me understand the reasons why the XML draft specs
exclude -so far- using Public IDs in links.
Best Regards
Alain Michard
Mediaculture - Direction du D?veloppement
INRIA - Domaine de Voluceau
BP 105
F-78153 Le Chesnay Cedex - France
Tel: +33 1 3963 5472 Fax: +33 1 3963 5114
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From tbray at textuality.com Fri Aug 8 18:02:27 1997
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 16:58:15 2004
Subject: FPIs as locators in XML-links ?
Message-ID: <3.0.32.19970808084641.008d9320@pop.intergate.bc.ca>
At 01:58 PM 08/08/97 +0200, Alain Michard wrote:
>I would be very interested to read some comments from SGML experts on the
>list, to help me understand the reasons why the XML draft specs
>exclude -so far- using Public IDs in links.
Two reasons, really. XML-Link is designed specifically for use in
the context of the Web, and on the the Web, things exist if they
can be addressed by URI's, otherwise not.
Secondly, whereas PUBLIC identifiers are very interesting and useful,
it is not the case that virtually every server and desktop in the
world comes with excellent free machinery to use them across the network,
which is the case with URLs. -Tim
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From tbray at textuality.com Fri Aug 8 19:18:37 1997
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 16:58:15 2004
Subject: FPIs as locators in XML-links ?
Message-ID: <3.0.32.19970808101550.008dfaf0@pop.intergate.bc.ca>
At 01:08 PM 08/08/97 -0400, Paul Prescod wrote:
>> Two reasons, really. XML-Link is designed specifically for use in
>> the context of the Web, and on the the Web, things exist if they
>> can be addressed by URI's, otherwise not.
>>
>> Secondly, whereas PUBLIC identifiers are very interesting and useful,
>> it is not the case that virtually every server and desktop in the
>> world comes with excellent free machinery to use them across the network,
>> which is the case with URLs. -Tim
>
>1. Don't these arguments apply equally to XML-Lang?
No. Links on the Web are based on URI's; that's a fact of life. If
you want another kind of link that isn't, go ahead and build it, but
our mandate was to build a Web-oriented hyperlinking facility. There is
no Web machinery that knows anything about FPI's.
>2. You've argued why PUBLIC identifiers will sometimes not be useful.
>You haven't argued why they will *never* be useful. They were put into
>XML Lang because some argued that they will sometimes need them. That
>applies to XML-Link equally.
Yes, you've said this many times. So far, the WG membership is
unconvinced.
>3. What about entities declared through system identifiers? Why can't I
>link to them through their entity names?
Because that's not how things are done on the Web. Of course, you in
XML you *can* say
> What is the point of "binary"
>entities if the "standard" linking and transclusion mechanism can't use
>them? Or to go the other way, why wouldn't the standard linking and
>transclusion mechanism be able to use the standard mechanism for mapping
>external resources into document names?
The key point is the use of the word "standard". The use of entities
and PUBLIC identifiers is standard only in the world of SGML. For
interoperation with the universe of Web documents, the only standard
way to do things is the URI mechanism.
To summarize, we were not trying to extend the SGML entity mechanism
to do network hypertext; we were trying to extend the existing Web
hypertext mechanism to be usable in XML.
Anyhow, this argument is over. Sorry. -T.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
From neil at bradley.co.uk Sat Aug 9 12:15:01 1997
From: neil at bradley.co.uk (Neil Bradley)
Date: Mon Jun 7 16:58:15 2004
Subject: 5 Whitespace Rules
Message-ID: <199708091014.LAA11574@andromeda.ndirect.co.uk>
I think it's time to pin down some rules or guidelines regarding
the use of whitespace. I am not suggesting that the following is
exhaustive or totally unambiguous, but maybe it is a starting point
for discussion. I would really like to see a small list of rules such
as the following being defined, as I am sure it will help avoid potentially
damaging confusion arising when products arrive and prove to be
incompatible.
One of the problems of defining rules for XML has been the grouping
of line-end codes with space separating characters under the 'S'
rule. By separating these concepts, it is quite easy to define rules
with are both backward compatible with SGML and HTML (very important
in its own right) and also intuitive.
While the idea of ignoring all line-end codes and manually inserting spaces at
the start of each line to compensate is at first sight attractive,
it is certainly not intuitive, and there are plenty of text files in existence
(including SGML and HTML files, of course), which do not follow this
convention.
--------------------
An application should remove or transform whitespace characters
received from the XML-processor according to the following 5 rules:
RULE 1. Every CR and LF code is regarded as a line-end signal, except
when it immediately follows the other code ([CR][LF] or [LF][CR]), in which
case it is discarded (and is also ignored, so has no effect on
calculations for the next character). This rule applies even in 'preserved' content.
/*
This rule standardizes input from documents prepared on Mac, Unix and
MS-DOS/Windows platforms.
[CR] ---> line-end
[LF] ---> line-end
[CR][LF] ---> line-end
[LF][LF] ---> line-end, line-end
[CR][CR] ---> line-end, line-end
[CR][LF][CR][LF] ---> line-end, line-end (because both LF's are
ignored)
By including this rule in preserved content, we avoid alternate blank
lines appearing in documents prepared on an MS-DOS system but viewed
on another system.
*/
RULE 2. A line-end code (or codes) immediately following a start-tag, PI or
declaration, or immediately preceding an end-tag, is discarded (except in
preserved content).
/*
[CR][CR]