[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Re: [office-metadata] Re: [office] Suggested ODF1.2items
Svante, Svante Schubert wrote: > Hi Patrick, > > why limit meta data to the XML structure? Err, well, we don't. At least in the sense that one can always add metadata to the content, but yes, I suppose it is always tied to XML structure. Even if that is simply span. I don't think you escape that by using milestones since there is always structure in the file that denotes the beginning and end of the application of the metadata. Milestones are one way to handle such data but note that they do no exist in relationship to the document hierarchy. > > Not everything is given in the same hierarchy. Actually I have argued privately with some of my fellow researchers in overlapping markup that non-overlapping structures are the special case and that overlapping structures are the general case. ;-) Look at any printed work and note that paragraphs commonly "overlap" the page boundaries. > > A user might mark half of a table and the following paragraph and > relate it with an arbitrary semantic. > Shall we pop up an error message or round to next full element? > Good example. But, let's not confuse what the user is "marking" with what is happening on the other side of the screen. Say that a user selects half a table and the following paragraph to attach some arbitrary semantic. On the markup side of the screen, what is to prevent me from using well formed markup to mark the half-table and paragraph separately but pointing to the same arbitrary semantic? > Have you any bad feelings with the second attribute based approach? > If I am reading it correctly it looks like you have a milestone in the first one and an open/close element in the second, although they are concatenated. Yes? Steve DeRose actually did a presentation at Extreme Markup on a variation we developed for a Bible encoding project where there are two milestone elements that are linked by startID and endID (only one allowed in each) to deal with overlapping markup. Your xsl:key suggestion would work here. I have misgivings about the use of a milestone plus a more normal start/end tag. Mixing markup techniques as it were seems prone to problems. Would you allow two milestones in addition to milestone plus a regular element? That would give implementers two ways to accomplish the same end, not often a good idea. > Best regards, > Svante > (-: who is having a great day and is hoping you enjoy it, too :-) > Great! I finished printing OOXML today and when I get it bound into binders I will post a photo of it. Some leisure reading for the holidays. ;-) Hope you continue to have a great day! Patrick > Patrick Durusau wrote: > >> Svante, >> >> I just saw Daniel Carrera's response to this proposal. >> >> I have spent a number of years working on the overlap problem in >> markup so it is no stranger but what I am missing in this case is why >> a field would ever need to cross markup boundaries? >> >> Hope you are having a great day! >> >> Patrick >> >> Svante Schubert wrote: >> >>> Hi everybody, >>> >>> Patrick Durusau wrote: >>> >>>> Florian, >>>> >>>> Florian Reuter wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> the problem here is that we need to be able to encode documents like >>>>> >>>>> <p><span/><field-start/><span/><p> >>>>> <p><span/><field-end/></p> >>>>> >>>>> >>>> >>>> >>>> Did you mean: >>>> >>>> <p><span/><field-start/><span/></p> >>>> <p><span/><field-end/></p> >>>> >>>> >>>> Ah, are both <field-start> and <field-end> empty elements? >>>> >>>> To put it another way: What is the content that is being surrounded >>>> by the <field-*> tags? >>>> >>> >>> The problem of marking an area that is not relative to the XML >>> structure can be solved in different ways, I see two simple approaches: >>> >>> >>> 1) As Florian suggested, using an empty start and end tag as marker: >>> >>> Florian's approach (a little more complicated example, by adding a >>> further span) >>> <p><span/><field-start/><span/></p> >>> <p><span/><field-end/><span/></p> >>> >>> >>> Pro - The size: >>> Only two XML elements for marking the area >>> >>> Con - The new complexity for XML based applications: >>> From the view of a XML element it is very hard to find out if part >>> of a certain field/area or a field/area at all >>> >>> >>> >>> 2) By a 'concatenation' of elements using the same attribute: >>> >>> Let's call it the XML friendly approach: >>> <p><span/><span meta:class="foo"/></p> >>> <p><span meta:class="foo"><span/></p> >>> >>> >>> Pro - Easy to handle for XML based applications: >>> e.g. XSLT uses xsl:key >>> >>> Con - The Size: >>> Often more than two XML attributes for marking an area >>> >>> >>> Weighting the pro/con I see currently no reason to use the first >>> approach and neglect the second, have I overseen something? >>> >>> Best regards, >>> Svante >>> >>> >>> >> > > > -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]