OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] discussion about a feature request regarding user inputfields

So here's some thoughts ...

First, I think all fields should work similarly in the sense of being
able to contain formatted content within them, as well as potentially
multiple paragraphs, etc. I'd suggest the content of fields be 
well-formed XML (rather than using the start/end approach). I'm not sure 
how best to solve Oliver's concern, but maybe the span I suggested would 

I had not actually dealt with text:input-field before. So the question
I'm left with is what -- if anything -- might be the distinction
between this field and the new text:meta-field?

It seems to me that text:input-field is intended to conform to broadly
similar use cases as the new inline metadata support. In this sense,
it might (at least optionally) be understood as a UI mechanism to allow 
for inline metadata input, where the object of the triple is a literal 
(either string, or XML literal).

If I'm right, then, we need to make sure the new metadata attributes
are allowed on the input field (and any other similar fields) for cases 
where someone wants to add additional semantics on top of that input 

The intention behind text:meta-field, by contrast, is to link to
structured RDF data. So user inserts a reference to a patient, or a
customer, or concept, and this field encodes that, displaying some
representation of that resource, and perhaps allowing additional
functionality to be bound to it. In other words, the content of the 
field is generated from RDF/XML metadata.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]