On Wed, 4 Jul 2007, Kirill Subbotin wrote: > Internal XML text schema > ------------------------ > > *Element groups: > > %block = h1-h6 | p | embed | table | ol | ul | literal | %custom-block > %inline = #text | br | strong | em | sub | sup | strike| u | embed-inline | > link | anchor > | code | %custom-inline > > > *Elements: > > <document> > A root node of the document. > Attrs: Namespace definitions. > May contain: %block > > <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. And I wonder, why do we need to keep BC things here (anchor_name)? > <p> > Attrs: class, id > May contain: %inline > > <br /> > > <em>,<strong>,<sub>,<sup>,<strike>,<u> > Attrs: class, id > May contain: %inline > > <literal> > Attrs: class, id > May contain: #CDATA > > <code> > Attrs: class, id > May contain: #CDATA Do we need both literal and code? > <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). > > <colgroup> > Attrs: class, id, width, align, valign > May contain: col > > <col> > Attrs: class, id, width, align, valign > > <thead>,<tbody>,<tfoot> > Attrs: - > May contain: tr > > <tr> > Attrs: class, id > May contain: td, th > > <td>,<th> > Attrs: class, id, colspan, rowspan, scope > May contain: (%block;)* | (%inline;)* > > <ol>,<ul> > Attrs: class, id > May contain: li > > <li> > Attrs: class, id > May contain: (%block;)* | (%inline;)* > > <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. > > <anchor /> > Attrs: name > > <embed /> > Attrs: class, id, view, src, align, link:href, link:url_id, link:target, > link:view > > <embed-inline /> > Attrs: class, id, view, src > > *Custom elements: > > <custom:mytagname /> > Attrs: custom:myattr1, custom:myattr2... > > > Simplified XML text > ------------------- > > 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). > 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. > 2) <link> element use 'href' instead of 'url_id' for external urls > (see issues). > 3) It is not necessary to write namespace prefixes, they areadded > automatically. (only if there is no regular attribute with the same > name) > > So basically it is almost the same XML, without paragraphs, but still > with many tags. > There is a proposition to make it even simpler and more close to ReST. > Tags that have no attributes can be presented with simple markup. For > instance list that have no attributes will look like this: > > * item 1 > * item 2 > > 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. > 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 :) > > - 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://" ? > - Do we need <caption> element for tables (like in XHTML) or is it > enough to have an attribute? Attributes are defined for XML as things that humans don't care about, and are mainly used for the machine processing. THerefore, as the caption is a human thing, I would not put this in an attribute but as an element *only*. (http://xml.coverpages.org/holmanElementsAttrs.html) > - Do we need <colgroup>? What does it do? :-) regards, -- Derick Rethans eZ components Product Manager eZ systems | http://ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
