[tei-council] num

[Lou Burnard]

You could always go ahead and implement it in your ODD -- that way you 
could test how useful the proposed solution actually is!

Ahead of it in the queue at the moment is <pc>, which needs more work. 
But I still  hope to get both of them into the next release.



Gabriel Bodard wrote:
> Well, it's essential for me to be able to record date spans with 
> imprecise start points, so will be another blocker for P5 conversion 
> of EpiDoc.
>
> Anyway, I don't mean to harry you, but I'm just hoping it might slip 
> under the door before the next release. Again, anything I can do to 
> help (e.g. with examples, GLs, etc.) just shout!
>
> G
>
> Lou Burnard a écrit :
>> Still on the list, sorry.
>>
>> Implementing it isn't too difficult though I'm still a bit dubious 
>> about how useful it really is.
>>
>>
>> Gabriel Bodard wrote:
>>> Sounds fine to me... it solves the problem I have with fractions, 
>>> and means I have less to change in my XML.
>>>
>>> (Any word on when <precision/> will be implemented?)
>>>
>>> Thanks,
>>>
>>> G
>>>
>>> Lou Burnard a écrit :
>>>  
>>>> There having been no dissenting voices to this proposition, and it 
>>>> being a lot easier to implement, I am now planning to go ahead and 
>>>> change the definition of data.numeric to permit things like
>>>>
>>>> <num value="22/7">pi</num>
>>>>
>>>>
>>>> James Cummings wrote:
>>>>    
>>>>> Sebastian Rahtz wrote:
>>>>>      
>>>>>> Lou Burnard wrote:
>>>>>>        
>>>>>>> This was indeed one of the options I proposed in my email. But I 
>>>>>>> wondered whether expanding the meaning (or reducing the 
>>>>>>> constraints) associated with "data.numeric" might not be 
>>>>>>> considered to be flouting the Birnbaum doctrine...
>>>>>>>           
>>>>>> not at all. call it data.extendednumeric if you like. Birnbaum does
>>>>>> not disallow expansion
>>>>>>         
>>>>> And just to remind people, since this is occasionally trotted out 
>>>>> as an excuse, that said doctrine does *not* prohibit breaking 
>>>>> backwards compatibility.  In fact it says: "Council should instead 
>>>>> feel authorized to break backward compatibility when Council 
>>>>> concludes that the advantages of doing so outweigh the 
>>>>> disadvantages."  So it is really just a question of whether we 
>>>>> think doing so outweighs the disadvantages of not doing so.
>>>>>
>>>>> http://www.tei-c.org/Activities/Council/Working/tcw09.xml
>>>>>
>>>>> On the question of data.numeric, I see little problem in extending 
>>>>> it (or adding an additional datatype as suggested above).
>>>>>
>>>>> -James
>>>>>       
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>     
>>>   
>>
>