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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: Re: [office] Re: [office-metadata] Re: [office] Suggested ODF1.2 items


Hi Patrick,

why limit meta data to the XML structure?
Not everything is given in the same hierarchy.
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?

Have you any bad feelings with the second attribute based approach?

Best regards,
Svante
(-: who is having a great day and is hoping you enjoy it, too :-)

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
>>
>>
>>
>


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