Lists Home |
Date Index |
- From: "Rick Jelliffe" <firstname.lastname@example.org>
- To: <holstege@firstfloor.COM>
- Date: Fri, 10 Oct 1997 01:31:03 +1000
This discussion probably should be on comp.text.sgml, so i wont continue it
apart from this.
> From: Mary Holstege <holstege@firstfloor.COM>
> I don't think this is such a bad solution. Your only alternatives are to
> have to define the content model all over again (which defeats the whole
> purpose) or somehow be able to identify which part of the parent content model
> the new stuff needs to insert itself after, which strikes me as too brittle
> to be workable.
I have proposed to ISO WG8 a keyword #ANY that can be allowed in a content
model, meaning that one of any element type can be put there. This allows
base elements types to maintain their integrity.
> It is a mistake for ordering information to be part of the abstract syntax
> declaration in the first place, IMHO. Presentation order is, well, a
> presentation issue and has no business being declared anywhere other than in a
> presentation rule (style sheet, if you will).
I couldn't disagree more. Without a fixed ordering, you have to either use in-memory
processing of data or you have to have an extra pass (or step) in your stream
processing to reorder the data. Stream-based text processing is a very useful
technique. Maybe memory is cheap enough now that, with virtual memory, we can
forget about stream processing, but I don't think so yet. But the requirement
that things should be declared before they are used (where possible) that underpins
stream processing is greatly aided by fixed-order processing.
If we don't have fixed orderings possible, we have to key everything. You may
as well use a database!
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)