[
Lists Home |
Date Index |
Thread Index
]
- From: Peter Murray-Rust <peter@ursus.demon.co.uk>
- To: xml-dev@ic.ac.uk
- Date: Sat, 13 Dec 1997 19:36:41
At 09:59 13/12/97 -0800, Tim Bray wrote:
>At 03:19 PM 13/12/97, Peter Murray-Rust wrote:
>
>I agree with Peter that we should just buckle down and get on with what used
>to be known as XAPI.
>
>But my approach would be quite different. I think that the first step
I'm missing something :-) Your approach below seems almost identical to
what I was suggesting.
>should be the end-user's API, the kind of thing that someone using a SMIL
>or RDF processor would need. Such a person really doesn't want to wrestle
>with entities and references and PIs and marked sections; all they want
Agreed - and they wouldn't be in what I wanted as well.
>is elements and attributes and the basic doctype info; they want the
yup
yup
yup
>processor to deal with entities and refs and quote marks and white space in
>markup and encodings and so on.
>
>This would go a long way to address the whinings of the RDF & SMIL type
>people, who thought XML just meant elements and attributes. I think that
>from their point if view, it should be, all the other stuff in the syntax
>is strictly to support authoring and management convenience.
>
>It should come in event-stream flavor and tree flavor.
>
>Minimal event stream API:
>
>1. Doctype, returns: root type, external subset system/public idents
I would like the elements as well. If the parser doesn't do them, we just
return null. But if it does...
>2. Element start, returns: type, element name-value pairs, whether it's empty
is "type" the elementType? This is the sort of terminological problem we
have.
>3. Text
>4. End Element, returns: type
>
>Minimal tree API:
>
>1. Document, with methods: root type, system ID, public ID, root element
>2. Element, with methods: parent, children, attributeValueByName,
allAttributes
>3. Attribute, with methods: name, value
>4. Text (presumably hiding lazy evaluation)
Sounds OK.
>
>I acknowledge this is grossly insufficient for basing an editor on. You want
I don't want much for an editor. Just the attribute stuff and contentspec.
I don't want PE's, comments, marked sections and so on.
>that, use the DOM. Only a few choices have design implications:
>
>1. How are children returned; possibilities would be to have Element and
> Text crammed into the same class with a method for asking which is which,
> or have separate Text and Element classes, then children returns an Object
> array or a Vector, and you can find out what kind of child each member
> is using the instanceof operator. I favor the latter, Lark does this
I'm easy - **as long as we all agree**
>
>2. Whether it's worthwhile putting children into, as opposed to a native
> array or Vector, a special ChildList class with enumerator and indexing
> so you can hide a lazy-evaluation behind it. I favor the latter, the
which is 'the latter'? :-)
> DOM does this but Lark doesn't.
>
>3. Whether the processor should be required to coalesce adjacent Text
> objects. Suppose you have <a>foo <!--comment--> bar &ref; <?pi?>baz</a>,
> it's immensely less work if the processor can give this to the app
> as 4 Text chunks. I think most of the processors do this now.
I don't have a problem here...
>
>If I formalized and published this, it would look a lot like part of
>Lark's interface, but I bet all the other parsers could implement it.
>Should I? -Tim
I bet they could. It is very important, however, that everyone agrees on
the terminology.
I have never seen this as a difficult problem. I think it would take a week
to come up with a reasonable working draft. I hope that XML-DEVers will see
the value of a simple interface and not - as has happened before - keep
getting more and more complex. the three parsers we have are simple - it's
a slightly depressing situation that we haven't got an interface for them
to use.
I suggest that Tim goes ahead, but I'll also produce my interface from the
spec. After all, that will show what the *consumer* (i.e. JUMBO) would
like. As always I shall be happy to junk anything I do if it helps us make
progress :-)
It might also be useful for us to set ourselves a deadline.
P.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|
