Derick Rethans wrote: >> <h1>-<h6> >> Attrs: class, id, anchor_name (for BC) >> May contain: %inline > > I am not sure if this is such a good idea. Yes, it is closer to XHTML, > but that should not be the deciding factor only for the way how we store > content. I've always found one of the stronger points that eZ Publish > cares about the structure more than layout. Although our current > structure does have some issues, I do think that we should keep the > nested things like we have now. As only reason why not to do that I > heard that it is a performance issue - without having seen data and > benchmarks that backs this up.
Personally I like <section>s too, as they make document look more structured. Although I'm not sure how handy to edit it, because of many indentation spaces. But anyway what's the reason to have sections in the DB where no one sees it ? If we really need a possibility to edit internal XML (Do we?), I would agree that having sections is a good idea. But on the other hand I have doubts that people will like the format that look like XHTML 1, but a bit different. We could follow XHTML 2.0 draft in this case, not to invent a wheel, but it is just impossible as it has totally different schema. > And I wonder, why do we need to keep BC things here (anchor_name)? AFAIK we need to care about keeping the layout on the existing installations. (Am I wrong?) I would like to remove such attributes but in this case AFAIK we should: - Replace them with something else in upgrade script, and then: ~ Replace variables in templates automatically? (could be hard) ~ Emulate old template variables? ~ Add some BC settings? > Do we need both literal and code? Yes, because the first one is block (like <pre) and the second is inline. >> <table> >> Attrs: class, id, title, width, border, summary, caption >> May contain: col, colgroup, thead, tbody, tfoot > > I don't think we should have a "caption" and "summary" attribute, they > should be subtags (see my explaination below). I agree for "caption". But "summary" is an attribute in XHTML and I think there is a reason for this. >> <link> >> Attrs: class, id, title, href, url_id, view, target (for BC, deprecated) >> May contain: %inline > > I don't think we should put in BC things. This one is easy to drop. Although we should know how to explain it to people who used it. >> Simplified XML text format is intended to provide an easy input for >> the datatype, but not WYSIWYG. So to keep full control over the >> document, while not having to write tags. > I think we should change the name "Simplified XML" to something else, as > it is not XML. It voilates some of the wel-formedness rules (Example is > the <literal> tag in which you can use > and < without problems). well, "simplified xml" is not XML definitely, althogh they have something in common. If there is a better name for this, I agree to rename it. Half-XML ? :) >> Differences from internal format are: >> 1) <p> and <br/> elements are presented with linebreak characters, >> with 2 and 1 linebreaks accordingly. (only if <p> has no attributes) > I often find it annoying that a single line break creates a <br/> > already. Very often it happens that I have to paste in text from some > text file, and then I have to mess with removing the hard \n's from > there. We should probably add some option for this in ezp. It could be a checkbox in the interface f.ex. And btw, this issue also touches OE as well. >> but if there are any attributes, it become looking like XML: >> >> <ul> >> <li attr='value'>item 1</li> >> <li>item 1</li> >> </ul> > > I think we should not try to do this. I would prefer it if ezp just > supports many formats as input, such as "Simplified XML", "Datatype XML" > and "ReST". It's useful to be able to paste "datatype xml" as it can be > generated easily with other XML processing tools, where as "ReST" is > really easy to write yourself. Being able to select which input method > somebody prefer is IMO better than trying to mix them. However, for the > list types (ul, ol) we might want to make an exception. I agree that having just different formats of the input is a better idea. But what to do with existing data when user tries to edit it in the ReST format? We have to display a really big warning about that all attributes are lost. >> Issues >> ------ >> >> - In eZp links have only 'url_id' attr. for external URLs, but the URL >> itself is stored in the database. Probably we should store external >> URLs in href's as well to make it easier to convert between formats >> and to provide faster output. But in this case all XML blocks that use >> this URL have to be updated when you update URL in eZp. (which seems >> possible as we have ezurlobjectlink table and class) > This is a hard one... I don't like either of the two options :) Now I think we should just store "href" and no "url_id" at all. We have a ezurlobject link table anyway, so it's not a problem to search and update URLs when user change them from admin interface for example. >> - How to distinguish between node ID and node path in internal URLs >> like "eznode://ID" and "eznode://path/to/node" ? > Call them "eznodeid://" and "eznode://" ? May be "eznode://" and "ezpath://" in this case ? (for consistency with "ezobject://") >> - Do we need <colgroup>? > What does it do? :-) Groups columns. :) To apply some attributes to a group. Don't know what are real applications for this though. -- Kirill Subbotin Software Developer [EMAIL PROTECTED] | eZ Systems | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
