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] Groups - ODF_Element_Naming_01 (ODF_Element_Naming_01.pdf)uploaded


Bob,

Bob Jolliffe wrote:
> Hi Patrick
>
> I wasn't questioning your command of the English language.  'tis also my mother tongue.  Neither of which is entirely the point.
>
>   
Sorry, my point was that less ambiguity, which doesn't seem so to a 
native speaker is better, as a general rule.
> It just seems that whereas I strongly agree in principle with your aim, and particularly with regards consistency, I think your list may be a bit over eager.
>
>   
Perhaps, perhaps, but I would rather the TC decide explicitly that it 
wishes to have a policy and then to depart from it, as opposed to 
leaving people to wonder why we weren't consistent. For example, I will 
be greatly surprised if text:h and text:p don't persist forever. But, I 
do think the TC should say that they will persist, despite a general 
rule that would indicate to the contrary.

That gets everyone in the habit of not thinking of abbreviations, etc., 
for naming. Which is probably more important than correcting any 
particular instance of it.
> You also didn't say why "style:auto-text-indent" should be replaced with "style:automatic-text-indentation".  My question was whether the problem was with "indent" as a verb.  Is there a case to be made for consistency, that such attributes should not be verbs and does this then also mean the likes of "*-align" should be "*-alignment" etc?  Or is it that you are simply seeing "indent" here as an abbreviation of "indentation" and hence requiring correction?
>
>   
Ah, good point. I was seeing it as an abbreviation.
> When we do finalise on a list, and particularly if it includes renaming some attributes from previous versions, I believe a simple DSRL map will be a very tidy way of expressing those changes.
>
>   
Excellent suggestion.

Hope you are looking forward to a great weekend!

Patrick
> Regards
> Bob
>
> ----- Original Message -----
> From: "Patrick Durusau" <patrick@durusau.net>
> To: "Bob Jolliffe" <bobj@dst.gov.za>
> Cc: "robert weir" <robert_weir@us.ibm.com>, office@lists.oasis-open.org
> Sent: Friday, May 2, 2008 1:03:30 AM (GMT+0200) Africa/Harare
> Subject: Re: [office] Groups - ODF_Element_Naming_01 (ODF_Element_Naming_01.pdf) uploaded
>
> Bob,
>
> Bob Jolliffe wrote:
>   
>> Greetings.  We are still on an extended public holiday in SA which is why I've been so quiet ...
>>
>>   
>>     
> Cool!
>
> Just quickly I would note that I see these terms as a native English 
> speaker and so, yes, I have no doubt whatsoever about the expansion of 
> the abbreviations.
>
> However, having said that, note that I am a *native English speaker.*
>
> Moreover, it is a question of consistency. If you review the examples, 
> you will find that sometimes we use the shorter form and sometimes the 
> longer. If we had consistently used the shorter form, like we did with 
> text:p, then you might have an argument. A sturdy indefensible as Fowler 
> would put it.
>
> But, if we are ourselves inconsistent, then what are we honoring? Our 
> ability to not carefully check our own work for consistency?
>
> Aside to Rob: I will verify the presence of these in ODF 1.0 and 1.1 but 
> I am fairly sure they are there. As you might imagine, I am much more 
> concerned with ODF 1.2 issues than with uncovering legacy issues. ;-)
>
> I am working on the regex list, which I was doing in the context of a 
> larger review of the datatypes of all the attributes but that was taking 
> too long. I am recording observations as I go but mainly looking at the 
> attributes that will need regexes.
>
> For example, we say anim:audio-level is between 0 and 1, I assume 
> inclusive. But, schema says: double??? True that includes 0 to 1 but it 
> isn't how I would constrain that particular attribute. While the prose + 
> schema gives an answer, it isn't possible to validate the prose 
> restriction using the schema as written.
>
> Hope you are having a great day!
>
> Patrick
>
>   
>> Just a thought, but I think Martin Bryan's DSRL (Document Schema Renaming Language) which is part 8 of that long awaited project of SC34 WG1, ISO/IEC 19757 - DSDL, can make mapping between naming conventions (the old and the new, or perhaps the concise and the verbose) pretty straightforward to deal with and describe.
>>
>> But, generally I would go along with Rob's exceptions below.  Is there a synthesis to be had between the proposed guidelines?  In addition I think some joined up "words" like readonly and datasource have, for better or for worse, made their way into common currency.  dropdown for me is marginal.  nohref I agree must be hyphenated.
>>
>> I'm puzzled over:
>> "style:auto-text-indent" and "style:automatic-text-indentation".
>> I really prefer the former.  What is the problem with "indent"?  Is it that we don't want a verb here?  Do we then hit a similar problem with "style:vertical-align" and friends?
>>
>> Regards
>> Bob
>>
>> ----- Original Message -----
>> From: "robert weir" <robert_weir@us.ibm.com>
>> To: office@lists.oasis-open.org
>> Sent: Thursday, May 1, 2008 11:22:26 PM (GMT+0200) Africa/Harare
>> Subject: Re: [office] Groups - ODF_Element_Naming_01 (ODF_Element_Naming_01.pdf) uploaded
>>
>> Patrick, are you making a distinction between inconsistencies in new 
>> elements being added to ODF versus inconsistencies in ODF 1.0/ODF 1.1 
>> names?
>>
>> If it is possible to break these out, that would be great.
>>
>> Things that we're adding to ODF 1.2 we should be able to freely rename, 
>> retype, whatever.  But for existing names we'll need to go through a 
>> deprecation cycle.
>>
>> Also, I don't mind some abbreviations where they are in every day use.  So 
>> min/max/auto/multi are blessed by age.  The best advice I ever heard on 
>> abbreviations was that they were dangerous when different people could 
>> abbreviate the same word differently, and this will lead to error.  So 
>> what is the abbreviation for "table"?  Is it "tbl" or is it "tab" or is it 
>> "tb"?  There is no accepted abbreviation.  So it should always be written 
>> out.  But what is the abbreviation for "automatic"?  I think you get 100% 
>> of people to agree that the answer is "auto".  So maybe that is a safe 
>> abbreviation to use.
>>
>> Other good guidelines are:  It should be easily pronounceable  and 
>> understood when spoken.   Odd requirement for an XML standard, but if this 
>> is not true, then it is hard to review the standard with everyone over the 
>> telephone!
>>
>> It is a balancing act.  My principle is based on the belief that computing 
>> power will continue to grow and become cheaper, while programmers will 
>> probably not get much smarter than they are.  In other words, technology 
>> improves faster than evolution.  So making life more difficult for 
>> programmers in order to save a byte of storage is usually a poor 
>> trade-off, at least when measured over technology time spans of a decade 
>> or more.  On the other hand, names that are too long make will programmers 
>> lives more difficult as well, so common sense needs to prevail in the end.
>>
>> -Rob
>>
>> ___________________________
>>
>> Rob Weir
>> Software Architect
>> Workplace, Portal and Collaboration Software
>> IBM Software Group
>>
>> email: robert_weir@us.ibm.com
>> phone: 1-978-399-7122
>> blog: http://www.robweir.com/blog/
>>
>> patrick@durusau.net wrote on 05/01/2008 04:47:37 PM:
>>
>>   
>>     
>>> Greetings!
>>>
>>> I have finished inserting the markers for adding automatically generated
>>> text to the current draft so I celebrated by reviewing ODF for 
>>>     
>>>       
>> consistency
>>   
>>     
>>> on element and attribute names. ;-) 
>>>
>>> Ok, ok, each to his own! 
>>>
>>> Anyway, this document details 9 elements whose names need hyphens and 31
>>> that may need expansion of abbreviations. 
>>>
>>> I will be posting the listing for abbreviations in just a minute. 
>>>
>>> Hope everyone is having a great day!
>>>
>>> Patrick
>>>
>>>  -- Patrick Durusau*
>>>
>>> The document named ODF_Element_Naming_01 (ODF_Element_Naming_01.pdf) has
>>> been submitted by Patrick Durusau* to the OASIS Open Document Format for
>>> Office Applications (OpenDocument) TC document repository.
>>>
>>> Document Description:
>>> Use of hyphens and abbreviations in ODF element names.
>>>
>>> View Document Details:
>>> http://www.oasis-open.org/apps/org/workgroup/office/document.php?
>>> document_id=28168
>>>
>>> Download Document: 
>>> http://www.oasis-open.org/apps/org/workgroup/office/download.php/
>>> 28168/ODF_Element_Naming_01.pdf
>>>
>>>
>>> PLEASE NOTE:  If the above links do not work for you, your email 
>>>     
>>>       
>> application
>>   
>>     
>>> may be breaking the link into two pieces.  You may be able to copy and 
>>>     
>>>       
>> paste
>>   
>>     
>>> the entire link address into the address field of your web browser.
>>>
>>> -OASIS Open Administration
>>>     
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your TCs in OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
>>
>>   
>>     
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)



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