[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] summarizing recent suggestions
Hi Bruce, Bruce D'Arcus wrote: > Hi Michael, > > On Feb 28, 2007, at 4:04 AM, Michael Brauer - Sun Germany - ham02 - > Hamburg wrote: > >> >> What about calling the field just "text:meta", or "text:metadata", or >> "text:metadata-label" (I think the term label was suggested by Bruce)? >> If the name shall contain the term "field", then "text:meta-field" >> would be an option. >> >> My personal favorite actually is "text:metadata" or >> "text:metadata-label". > > I really have no strong opinion on this. I just chose the element names > to have something concrete to discuss. Does anyone else have any > opinions on the matter? I also have no strong opinion on this. So just take this as some suggestions, except that we should style with the "text" namespace for consistency reasons. >> >> "Typing" it somehow is a good idea. The concept we have for this >> already is to use namespaced names (see for instance chart:class >> attribute described in section 10.2): >> >> This would look like: >> >> <meta:field xml:id="0874801373 xmlns:contact="http://ex.net"; >> field:type="contact:Contact">foo</meta:field> >> >> For consistency reason I suggest that we reuse this concept, unless it >> would be inconsistent with other metadata standards, or otherwise >> inappropriate. > > I didn't realize ODF already supported using shortened names for > attribute content. > > In any case, that's merely a shorthand, after all. http://ex.net/Contact > == contact:Contact in your example. In that sense, we probably shouldn't > care whether it's a full URI or a namespace-prefixed one? Yes, it's some kind of shorthand. But is is the notation we are using already, so I would prefer to stay with it, if there are no strong reasons not to do so. >> In any case, a solution that requires that all RDF/XML streams are >> read to be able to update a field has the high risk that it introduces >> performance issues. Office applications for instance for performance >> reasons read images and embedded objects on demand only (that is, when >> they are displayed or edited). We should allow a similar behavior for >> metadata, too. A type plus maybe an IRI should allow that, but >> probably is not the only solution to this problem. >> >>> My alternative would be sometning like: >>> <field:field field:type="http://ex.net/Citation"; xml:id="0874801373"> >>> <field:source> >>> <meta:link meta:resource="urn:isbn:98239809" cite:pages="23"/> >>> <meta:link meta:resource="http://ex.net/1"/> >>> </field:source> >>> <field:body> >>> (Doe, 1999: 23; Smith, 2004) >>> </field:body> >>> </field:field> >>> I think it's just a practical matter how much the field should >>> contain to best enable document portability, including across file >>> formats (say OOXML; which looks more like the above). >> >> It's an interesting idea. For other text fields, the field description >> itself contains all data that describes what is displayed, but not the >> value that is displayed. Your idea seems to go into that direction. On >> the other hand, for metadata we assume that specialized implementation >> provide that string that is displayed. The data that describes what is >> displayed therefore is of value only for this specialized >> implementation. I therefore could also image that we actually move it >> to the RDF/XML streams that contain the actual metadata. The only >> thing we have to make sure is that it is easy to actually locate that >> data (see my comment above). > > The above is a generalization of the citation field, adapted for the new > metadata support. It is also similar to how MS does this, BTW. What I > encode in two meta:link elements, they encode in a single dumb attribute > (which would be really ugly to process with XML tools, BTW). Yes, I do understand that, and I have no objections to providing additional information in the content. But since we have the option to specify that as meta data, too, I would suggest that we look deeper into that idea if we agreed on the remaining issues. BTW: Section 11.7 defines generic properties for form controls. Maybe we can reuse that. > >>>> In this context, you forgot to mention Elias comment about the >>>> datatype attribute. RDFa gets the content as a XMLLiteral not as a >>>> string. Elais offered the datatype="plaintext" to be able to receive >>>> only text from the ODF element. Any link on this, Elias? >>> Yes, I left that out, but agree it should be in, and would support >>> Elias' suggestion on the datatyping. >> >> ODF has already a (limited) type support for strings, doubles, >> date/times and durations. See section 6.7.1. This support is based on >> xsd datatypes and already provides a support for data styles. If we >> add type support for metadata, I suggest that we define them based on >> what we have already (the current metadata draft actually says so >> already). > > Yes, makes sense. But do we need to add a plaintext type then? I don't know. My concern is more about those data types, that usually are not displayed literally, like dates and durations. >> >> This would be different if we add metadata attributes to <text:span> >> element. When doing so, we would alter the way <text:span> element are >> used. For this reason (and only for this reason), I would prefer to >> introduce a new element. > > So, for example, putting the attributes on table cells would be fine? If it is reasonable from the metadata perspective that a table cell has a "meta:about" and an "meta:property", and maybe also an "meta:resource", and if these attributes must appear simultaneously, then this would be okay for me. Where I would have concerns is if would allow table cell elements that have only a "meta:about", and where we assume nested elements take the "meta:property" attributes, because this would cause issues when editing such documents with a WYSIWIG application. > Bruce > Michael -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]