OASIS Open Document Format for Office Applications (OpenDocument) TC

Dear TC,

since I get a lot of question whether my “enhanced fields” will use text:meta-fields I'd like to restate my request.
In order to be able to encode WW-like fields I need the text:meta-field to be enhanced such that it can start in the
middle of a paragraph and/or end in the middle of another paragraph.

So enhancing the text:meta-field --- similar to bookmarks would solve the technical problem and would enable me to use
text:meta-fields to encode WW-like fields.

My request is: Can we additionally add a 

On 10/27/07, Florian Reuter 

Hi Florian,

Bruce D'Arcus wrote:
> On 10/27/07, Florian Reuter 

Hi Florian, all

looking at the long thread, it seems to me that we have multiple options 
to solve the issue, and maybe need some more discussions to find the one 
that is most appropriate. Please don't hesitate to continue your 
discussions on the mailing-list. In addition to that, I would like to 
suggest that we make this topic the top agenda item of our call next 
Monday, November, the 5th. I think it would be good if you and the 
metadata SC members could attend to the call.

Best regards

Michael

BTW: In case we use meta data features to represent input fields, we 
should not forget to actually specify the specific ontology for this.



Florian Reuter wrote:
> Dear TC,
> 
> since I get a lot of question whether my “enhanced fields” will use text:meta-fields I'd like to restate my request.
> In order to be able to encode WW-like fields I need the text:meta-field to be enhanced such that it can start in the
> middle of a paragraph and/or end in the middle of another paragraph.
> 
> So enhancing the text:meta-field --- similar to bookmarks would solve the technical problem and would enable me to use
> text:meta-fields to encode WW-like fields.
> 
> My request is: Can we additionally add a 

Hi Florian, all

looking at the long thread, it seems to me that we have multiple options 
to solve the issue, and maybe need some more discussions to find the one 
that is most appropriate. Please don't hesitate to continue your 
discussions on the mailing-list. In addition to that, I would like to 
suggest that we make this topic the top agenda item of our call next 
Monday, November, the 5th. I think it would be good if you and the 
metadata SC members could attend to the call.

Best regards

Michael

BTW: In case we use meta data features to represent input fields, we 
should not forget to actually specify the specific ontology for this.



Florian Reuter wrote:
> Dear TC,
> 
> since I get a lot of question whether my “enhanced fields” will use text:meta-fields I'd like to restate my request.
> In order to be able to encode WW-like fields I need the text:meta-field to be enhanced such that it can start in the
> middle of a paragraph and/or end in the middle of another paragraph.
> 
> So enhancing the text:meta-field --- similar to bookmarks would solve the technical problem and would enable me to use
> text:meta-fields to encode WW-like fields.
> 
> My request is: Can we additionally add a 

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:

> looking at the long thread, it seems to me that we have multiple options 
> to solve the issue, and maybe need some more discussions to find the one 
> that is most appropriate. Please don't hesitate to continue your 
> discussions on the mailing-list. 

I think we all agree the best solution is the last one Florian posted: 
to allow paragraphs within text:meta-field. That solves his use case, 
but does not require new elements.

...

> BTW: In case we use meta data features to represent input fields, we 
> should not forget to actually specify the specific ontology for this.

Yes, though an interesting question how.

Bruce

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:

> looking at the long thread, it seems to me that we have multiple options 
> to solve the issue, and maybe need some more discussions to find the one 
> that is most appropriate. Please don't hesitate to continue your 
> discussions on the mailing-list. 

I think we all agree the best solution is the last one Florian posted: 
to allow paragraphs within text:meta-field. That solves his use case, 
but does not require new elements.

...

> BTW: In case we use meta data features to represent input fields, we 
> should not forget to actually specify the specific ontology for this.

Yes, though an interesting question how.

Bruce

Hi Florian, hi TC,

Florian recently presented his work on OOo on enhanced input fields here 
in Hamburg to the Sun OpenOffice.org Writer team.
I support his feature request for the input field to have a 
multi-paragraph-spanning input field and formatting for its content.

I've got mixed feelings with allowing something like
XXX
AAA
	
BBB
		
CCC
	
	DDD

ZZZ
The merging of paragraph part "AAA" with paragraph "BBB" and paragraph 
"CCC" with paragraph part "DDD" causes the mixed feelings. I'm also 
asking me what happens to the paragraph attributes from paragraph "AAA" 
and "BBB" respectively "CCC" and "DDD" during the merge, if they are not 
the same.

What about the following solution?
XXX

ZZZ
The new optional elements 

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:

...

> The merging of paragraph part "AAA" with paragraph "BBB" and paragraph 
> "CCC" with paragraph part "DDD" causes the mixed feelings. I'm also 
> asking me what happens to the paragraph attributes from paragraph "AAA" 
> and "BBB" respectively "CCC" and "DDD" during the merge, if they are not 
> the same.

Hmm ... good point.

> What about the following solution?
> 
XXX
> 
> 
ZZZ
> The new optional elements 

On 29/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
Microsystems 

Hi,

Dave Pawson wrote:
> On 29/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
> Microsystems 

On 30/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
Microsystems 

Hi Dave,

Dave Pawson wrote:
> On 30/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
> Microsystems 

On 30/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
Microsystems 

On Tue, 2007-30-10 at 13:01 +0000, Dave Pawson wrote:
> On 30/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
> Microsystems 

On 30/10/2007, Andreas J. Guelzow 

On Tue, 2007-30-10 at 17:03 +0000, Dave Pawson wrote:
> On 30/10/2007, Andreas J. Guelzow 

Dave,

Sorry for the recent silence. A cable system acquisition and following 
"upgrade" has toasted my access for the last several days. :-(

Dave Pawson wrote:
> On 30/10/2007, Oliver-Rainer Wittmann - Software Engineer - Sun
> Microsystems 

Patrick Durusau wrote:

...

> We already "break" the tree model, such as with bookmarks, so I don't 
> see that as a real drawback.

More importantly, as Oliver said, there's not necessarily a need to 
"break the tree" (if Dave had read the whole thread ;-)).

> But the first question I would ask is for an example of a 
> "multi-paragraph spanning" input field.

Patrick, Florian's already posted an example. See top-of-thread.

> It isn't clear to me what a "multi-paragraph spanning" input field would 
> look like?
> 
> Particularly in a text:meta-field context.
> 
> I understand what is meant by "multi-paragraph spanning" so I suppose 
> where I stick is input field? Do you mean that the input field could 
> generate content to replace part of the content of one paragraph, any 
> number of other paragraphs and then part of the content of a concluding 
> paragraph? (in continuous order)

This is what's confusing to me, and it goes back to question I earlier 
asked: what *is* a field?

Bruce

Bruce,

Bruce D'Arcus wrote:

On 10/30/07, Patrick Durusau 

Bruce,

Bruce D'Arcus wrote:
> On 10/30/07, Patrick Durusau 

On 10/30/07, Patrick Durusau 

On 30/10/2007, Bruce D'Arcus 

"Dave Pawson" <dave.pawson@gmail.com>
wrote on 10/30/2007 06:46:34 AM:


>

> What technical justification is there for breaking the xml tree model
please?

> 

Could someone please post the specific section and
paragraph number in the ODF specification which we are proposing to change?
  Remember "field" is an ambiguous term in ODF, which could
refer to either form fields (Chapter 11 "Form Content") as well
as text fields (Chapter 6 "Text Fields").  I think it will
help if we're all on the same page.

Also, I'd like to see a use case posted.  I've
seen Florian's example, but that doesn't really motivate what is being
asked for.  Is the intent, for example, to be able to have fields
that contain arbitrary rich text?  If we can nail down what the use
case is, then we can discuss the best way of achieving it.

I observe that today in OO Writer, a user can select
portions of text from two adjacent paragraphs and mark the selection as
bold.  This is stored using text:span for the bolded selection in
each paragraph.  Have we explored whether such an approach is applicable
with fields?

But I must say that I see great benefits to being
able to say that a field, of either variety, contains data of a single
type. By "type", I mean a singly rooted XML element like <p>,
a real subdocument, not a "document fragment".  For XForms
use, I believe this is mandatory.  

Introducing markup tags that cut across the logical
structure of the document in arbitrary ways would bring a large increase
in complexity to the processing of ODF.  So, let's make sure we absolutely
need this before we add it.   


-Rob