[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: Fieldmarks: Nesting?
Hi Rob, > But I I understand correctly, the net effect is to take a portion of > paragraph content, possibly crossing paragraphs, and associate with it a > name, a type, a lock state and a set of name/value attributes that "SHOULD > be preserved". Exactly. And this is what bookmarks do. Again the only thing I'm proposing add a fieldmark in addition to a bookmark so that we can differentiate between user marks and script generated marks. The reason I added the syntactic sugar like (propName, propValue) pairs is that I dislike string encodings like FIELDMARK /PROP1 VALUE1 /PROP2 VALUE2 etc... ~Florian >>> <firstname.lastname@example.org> 05/07/08 12:05 AM >>> It sounds like you are saying that bookmarks are stuff we stick in ODF for special plugins to look at. But fieldmarks are entirely different. They are stuff we stick in documents for different special plugins to look at. I don't think the user-generated versus script-generated distinction is real. From a document format standard perspective, I don't think we can assume anything about who or what uses it. It is XML. One application might have users enter it, another application by enter the same stuff via a script, another might use trained monkeys. But I I understand correctly, the net effect is to take a portion of paragraph content, possibly crossing paragraphs, and associate with it a name, a type, a lock state and a set of name/value attributes that "SHOULD be preserved". So it does make be wonder what the relationship between this, bookmarks and meta data should be. It really seems like we have one generic mechanism and two specific mechanisms that are not making use of the general mechanism. That can't be good. Especially if we're going to ask for applications to preserve these extensions, even if they cannot interpret them, it will be good if we can have a single mechanism for this kind of stuff, so an application can write this preservation logic once and be done with it, rather than have three different versions of it in their code. -Rob "Florian Reuter" <email@example.com> 05/06/2008 05:09 PM To <firstname.lastname@example.org>, <email@example.com> cc <firstname.lastname@example.org> Subject Re: [office] Re: Fieldmarks: Nesting? Hi Rob, Hi Patrick, > I do like your request for a better statement of the use case. what part of: <quote from="http://wiki.oasis-open.org/office/Fieldmarks"> Many developers use bookmarks to mark areas of the document which are controlled by special plug-ins. Since bookmarks are not the right tools for this we propose to add a new element to the OpenDocument specification called fieldmarks. Fieldmarks are introduced to clearly differenctiate between user-generated bookmarks and code-generated bookmarks which we call fieldmarks. The main difference to bookmarks is that: fieldmarks need to be properly nested, fieldmarks have additional informations, like a type attribute and a sequence of (name, value) pairs which allow applications to store additional information about the content. </quote> is unclrear? Where is the disagreement? I really believe that bookmarks are for users and we need a element for developers. ~Florian >>> Patrick Durusau <email@example.com> 05/06/08 7:47 PM >>> Rob, firstname.lastname@example.org wrote: > > I guess my question is this -- what is the usual case in real > documents? Normal testing behavior? Or overlapping? What do users > typically do? We should optimize for the typical case, but at the same > time be expressive enough to handle all cases. > > It seems to me that the following are the only ways in which two > elements, a and b, can relate: > > a precedes b: <a>foo></a><b>bar</b> > > a follows b: <b>foo></b><a>bar</a> > > a includes b: <a><b>foo bar</b></a> > > b includes a: <b><a>foo bar</a></b> > > a and b overlap (not allowed in XML): <a>fo<b>o </a>bar<b/> > > (We should ignore OOXML's strange use in VML of: <a b="base64encoded > version of element b content"/> > Err, actually the overlap case is more complicated that it appears at first blush. There are some 13 cases of overlap, see: http://www.durusau.net/publications/Concurrent_markup.pdf > The overlap case can be expressed at least two ways: > > The way trick that Florian indicates: <a>fo<b-start/>o </a>bar<b-end/> > > or with a merge convention: <a>fo</a><a merge="true"><b>o bar</b></a> > > Just a thought. But if we think most cases are going to following > normal nesting rules (which is an open question), then why not just > use normal element nesting syntax and handle the exception cases with > a merge flag? I am not familiar with the "merge" convention, at least by that name. Do you mean that the "overlapping" element is broken into non-overlapping pieces and then "stitched" back together due to some attribute that matches up the pieces? I do like your request for a better statement of the use case. I think I would have stumbled on that eventually. Before we talk about the how (read markup), how about a statement of the goal that is desired. We may need additional markup like fieldmark, or may need an additional attribute or ...., who knows? But until we understand the goal, it is hard to say. Hope you are having a great day! Patrick > > -Rob > > Patrick Durusau <email@example.com> wrote on 05/06/2008 11:47:31 AM: > > > Florian, > > > > Yes, there is misunderstanding and I am afraid it continues in this > post: > > > > Florian Reuter wrote: > > > Hi Patrick, > > > > > > I guess there is a misunderstanding: > > > > > > So we have fieldmark-start and fielmark-end similar to bookmark- > > start and bookmark-end. Only difference is that > > > fieldmark-end do not have a name and thus they are always properly > nested. > > > > > > > > Err, having names or not isn't a condition for proper nesting. > > > > I think you mean being "well-formed" on which the XML standard says: > > > > > [Definition: There is exactly one element, called the *root*, or > > > document element, no part of which appears in the content > > > <http://www.w3.org/TR/2006/REC-xml-20060816/#dt-content> of any other > > > element.] For all other elements, if the start-tag > > > <http://www.w3.org/TR/2006/REC-xml-20060816/#dt-st> > > < http://www.w3.org/TR/2006/REC-xml-20060816/#dt-etag> is in the > > > content of the same element. More simply stated, the elements, > > > delimited by start- and end-tags, nest properly within each other. > > If that is what you mean by "nesting" then yes, we are on the same page > > thus far. > > > > > The fieldmark [without-start/end] is just an abbreviation. E.g. > > both representations are equivalent: > > > <fieldmark-start/>Hello World<fieldmark-end/> [That we way you > > would do it with bookmarks] > > > <fieldmark>Hello World</fieldmark> > > > Since the second form is much more convenient for XML processors I > > thought it was a good idea to say that this form > > > SHOULD be preferably written. > > > > > > > > Ok, but that isn't what you wrote or at least not how I read it. I read > > it to say you preferred the empty element form. > > > > I wouldn't say that the second form is more "covenient," it really > > depends on what you want to do. > > > > If you merely want to mark a location in a text, probably using the > > empty element is as good as any approach. > > > > BTW, simply becaue an element has names linking the start and end > > element doesn't mean that it can't be well-formed. It would be odd > to go > > to that much trouble if you were going to be well-formed but it > > certainly is possible. > > > However if you are doing a field marking like > > > <p>The following <fieldmark-start/>text is a fieldmark</p> > > > <p>spanning two paragraphs<fieldmark-end/>.</p> > > > There is no way using the second form. > > > > > > Make sense? > > > > > > > > OK, so you are now saying that well-formedness is *not* a goal for > > fieldmarks. > > > > Here is what I am hearing (warning: may not be what you mean): > > > > 1) fieldmark element must be able to contain content > > > > 2) that content may be in different elements so like bookmark, > fieldmark > > must not be required to be well-formed > > > > 3) but, in some cases fieldmark can be well-formed. > > > > It is the gap, which may entirely be me, between 2 and 3 that is > > confusing me. > > > > If fieldmark is *always* well-formed, that is one case. If not, it is > > another. But, we have to clearly understand which of those two are > at issue. > > > > Hope you are having a great day! > > > > Patrick > > > ~Florian > > > > > > P.S: > > > Maybe its a good idea to add this abbreviated form for bookmarks > > too... Current the <bookmark> element only marks one > > > position and not a span. So there is no alternative to writen > > bookmark-start and bookmark-end. > > > > > > > > >>>> Patrick Durusau <firstname.lastname@example.org> 05/06/08 4:27 PM >>> > > >>>> > > > Florian, > > > > > > A couple of questions before commenting on the fieldmark proposal: > > > > > > > > >> Fieldmarks are very similar to bookmarks, except that they need > to be > > >> properly nested. This is achieved by the fact, that a > > >> field:fieldmark-end does not have a ?name? attribute, but instead > > >> closes the last opened field:fieldmark-start element. The > > >> field:fieldmark element is short form of field:fieldmark-start and > > >> field:fieldmark-end. It SHOULD preferably be written instead of > > >> start-/end marks. > > >> > > > OK, on one hand you say that Fieldmarks should be properly nested and > > > use the rule that is typical of XML, the first end element closes the > > > nearest open element. > > > > > > But, then you say it should be written as an empty element, > <fieldmark > > > (lots of fieldmark attributes) /> instead of start/end marks. > > > > > > If the empty element form works, then nesting is not a > requirement. Yes? > > > > > > If nesting is a requirement, is the requirement that one fieldmark > has a > > > relationship to another? > > > > > > If so, nesting is only one way to represent such a relationship and > > > probably not the best one because the relationship is only implied. > > > > > > If you want to take action based on some relationsh> > > and not just whatever containment may imply. > > > > > > Hope you are having a great day! > > > > > > Patrick > > > > > > > > > > -- > > Patrick Durusau > > email@example.com > > Chair, V1 - US TAG to JTC 1/SC 34 > > Convener, JTC 1/SC 34/WG 3 (Topic Maps) > > Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 > > Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs > in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > -- Patrick Durusau firstname.lastname@example.org Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php