|Michael Brauer||Mar 12, 2003 9:51 am|
|Paul Grosso||Mar 12, 2003 1:45 pm|
|Daniel Vogelheim||Mar 13, 2003 12:02 pm|
|David Faure||Mar 16, 2003 8:18 am|
|Philip Boutros||Mar 17, 2003 9:27 am|
|David Faure||Mar 18, 2003 11:26 am|
|Paul Grosso||Mar 18, 2003 11:32 am|
|Philip Boutros||Mar 18, 2003 12:26 pm|
|Paul Grosso||Mar 18, 2003 12:42 pm|
|Uche Ogbuji||Mar 19, 2003 10:23 am|
|David Faure||Mar 21, 2003 8:49 am|
|Philip Boutros||Mar 24, 2003 7:40 am|
|David Faure||Mar 24, 2003 9:20 am|
|Michael Brauer||Mar 26, 2003 8:08 am|
|Subject:||Re: [office] Proposal for lists/numbered paragraphs|
|From:||Daniel Vogelheim (Dani...@sun.com)|
|Date:||Mar 13, 2003 12:02:44 pm|
Paul Grosso wrote:
[... proposal for lists + number element ...]
Coming from a structured markup world and not a WP one, I don't really understand this stuff. I can't really imagine what the use case is (I'm sure there are many in WP land, I just have a hard time imagining most things in WP land).
Is the number that is put in front of a numbered paragraph given as part of the style, or is it supposed to be computed automatically by counting something? And if the latter, what is counted?
In internal word-processor implementations (apparently, OOo Writer, WordPerfect, KOffice, Word share this trait), the style assigns the paragraph into a certain numbering domain. So all paragraphs in the same numbering domain receive a hierarchical numbering based on their numbering level.
The user interfaces often try to make this look more list-like, so one could argue that this is somewhat of a legacy. I'm tempted to take this position for Writer, but I'd probably get in trouble with my collegues... ;-)
Since I don't really have my head wrapped around this stuff, I can't really tell how this might work in an XSL world, but I'm nervous that this could cause problems for XSL.
I see your point. The problem, as I see it, is that the word-processing world has one kind of concept, and HTML, XSL, and basically any other XML format, have a different kind of concept. We want to do good XML, we need to represent word-processing documents, and hence we have a problem: How do we join these two? Both issues are listed in the charter as requirements, the former as 4) and 6), the latter as 1).
The OOo team has given an answer, one which has been accepted as the base specification: Use HTML-style lists, plus an extra 'continue-numbering' attribute. For all I can tell, this covers both requirements (being reasonable XML-wise, and being able to represent all documents), and hence it is a good answer. However, nothing is perfect, and this does place a burden on implementers for file format converters.
Instead, one could choose a representation that is close(r) to the word-processing side of things. This would make it easier for those people, but would make it harder for the structured markup people. And this is, in my view, the core of the discussion: There is inherent complexity in trying to bridge two worlds, and the committee gets to decide where to push that complexity, and how to slice it up.
The one suggestion is to do structured lists + continue-numbering. + structure where there is structure - pseudo-structure in some other places where list numbering is used without proper list. + easy for XML conversion - the structure may be hard to generate during conversions, and the pseudo-structure is ugly Essentially, the conversions is where we push the complexity to.
The next suggestion (Michael) uses that as base, but adds an 'escape' [i.e. declaring an individual paragraph to be listed at some level] to take away some of the burden from the filter people: + (optional) structure where there is structure - easy generation using the escape - redundant representation: there may be badly-behaved documents that don't generate any lists even where suitable - corollary from above: For complete processing one really needs to fully support both. Here, we distribute the complexity more equally, and various parties get to choose how much effort they want to put into it. Problem may be that the process may just not work very well if everyone chooses the easy way out.
The third suggestion would be to do things word-processor style completely, i.e. by having lists as a side-effect of formatting. + easy to generate from existing wp formats - structure may be hard to generate during XML processing - one may need alternative list structures for other parts of the format, i.e. for presentation modules. Here, we push the complexity over to the XML/structured markup side. You want lists? You make them! To some degree, this solution would fail the previously mentioned requirements 4)+6), while doing quite well on the 1) side. I'm not sure how good of a solution this is, given that the previous ones seem to cover all bases properly.
There has been an argument that goind the first route may be trying to be overly clean on this fairly arbitrary issue, while taking the easier way with other items (e.g. headers vs DocBook style sections). I'm not sure if I can follow this, but it was one of the given arguments and thus should be mentioned.
Paul, you said you sense trouble for XSL. Well, I think the necessary conversions are expressable as XSLT, if ugly. Given my taxonomy above, the third (and possibly second) solution places the complexity squarly in your lap, so you're quite right about sensing trouble. As I said before, I think it's doable, but I also think the other solutions are a better way to go.
As a general guideline, I would say that 'clean' XML solutions are to be preferred _if_ they can represent existing documents. This seems to be the case with solutions 1 (and 2) above. If we _cannot_ find a 'clean' XML way to represent existing documents, we have a problem and will need to do funny stuff. Example: tabs. I don't think lists qualify here, because a workable, XML-like solution exists.
Hope this helps!