Re: Case of function names (Was: Re: [xsl] comments on December F&O draft)

> I think that you could argue it both ways

Yes every argument has two sides: (right and wrong:-)

> when the function name
> includes the name of a relevant data type from XML Schema, since those
> data type names use camel case. It depends on whether you think people
> will be more confused by the naming conventions of functions being
> unpredictable or by not using the same naming convention when
> referring to the built-in data types within function names as you do
> when referring to them elsewhere.

The old XSLT 1.1 draft went into great detail about mapping between the
lowercase-hypenated-style to the camelCaseStyle in order to preserve th
enature of xpath names.

If you are mapping xpath hyphenated names to a language that doesn't
allow - in names and conventionally uses camel case, then it is natural
to drop the hyphens and to camel case the component words. In particular
you _have_ to drop the hyphens when going in that direction. Thus it is
natural when going in the other direction _from_ a camel case naming
convention to do the opposite, to lowercase and add hyphens. Of course
schema names are qnames so could have hyphens, but don't, but I believe
the same principle should apply.

>  - xf:ID()    and  xf:id()
>  - xf:IDREF() and  xf:idref()
>  - xf:Name()  and  xf:name()
> 
> However, perhaps this issue could be side-stepped by not using
> functional syntax for constructors.

I believe these should change in any case. (Apart from anything else I
don't see any need for constructors at the user level as I commented in
my original F&O commnets list)

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Received on Monday, 7 January 2002 05:35:02 UTC