[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: Fieldmarks: Nesting?
Florian, Florian Reuter wrote: > 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. > > You have said you want to do this. Now, can you say why? What practical difference does it make? If the issue is "who" added the bookmark, that is a user or some *particular* script, that might be something of more general interest. For collaboratively edited documents for example. It might be useful to know which user added a particular bookmark. Is that similar to the need to distinguish scripts from users? Do you need to distinguish which script added a bookmark? Hope you are having a great day! Patrick > 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 > > > >>>> <robert_weir@us.ibm.com> 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" <freuter@novell.com> > 05/06/2008 05:09 PM > > To > <patrick@durusau.net>, <robert_weir@us.ibm.com> > cc > <office@lists.oasis-open.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 <patrick@durusau.net> 05/06/08 7:47 PM >>> >>>> > Rob, > > robert_weir@us.ibm.com 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 <patrick@durusau.net> 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 <patrick@durusau.net> 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 >>> patrick@durusau.net >>> 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 patrick@durusau.net 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]