+/** Determine whether the UTF-8 string @a name is both a valid XML "Name",
+ * and one that uses only ASCII characters.
+ *
+ * The XML Name production is defined at http://www.w3.org/TR/REC-xml/#dt-name
*
* @since New in 1.4.
*/
Peter N. Lundblad wrote:
> Julian Foad writes:
> > Malcolm Rowe wrote:
> > 1. Re. semantics: For this to be a public API, your new doc string is a good
> > description of the implementation, and these are acceptable semantics for a
> > public API, but its name ought to reflect the ASCII aspect of its semantics.
> >
> > At some later stage we're bound to want an "is_xml_name" with full UTF-8
> > semantics, and I don't think it's OK to later change the meaning that much.
>
> Yes, I think it is OK if we document the current limitation of this
> function. I object to renaming this to something including _ascii_
> (or whatever) because it will be cruft that no one will want to use
> when (if) the function is properly and completely implemented. Note
> that this function is new in 1.4, so are free to change its semantics.
Well, it depends on how we advertise (document) it. The way Malcolm has
described it, its purpose is clearly to allow only the ASCII sub-set, and
callers will have a right to rely on that.
The other way of doing this, "document the current limitation", is fine as long
as it is very clear, such as:
+/** Determine whether the UTF-8 string @a name is a valid XML "Name".
+ * Return TRUE if it definitely is, and FALSE if not or if this function
+ * is unsure. (Early implementations of this function recognise only
+ * the ASCII subset of XML "Names".)
> > 2. Re. r18202: that commit purports to avoid sharing variables
> > (svn_ctype_table) between libraries:
> >
> > That commit eliminated the single use of an svn_cytpe macro outside libsvn_subr
> > at the time, but did nothing to prevent such use. The email discussion said
> > that public access to svn_ctype_table[] was to be deprecated, which would
> > require the svn_ctype_* macros to be converted to functions, but that has not
> > been done. Now there are other uses outside libsvn_subr, so presumably the
> > Win32 DLLs again don't build/work properly - is that the case?
>
> I guess so.
>
> > I think that commit wasn't a proper way to solve the problem. If we solve the
> > variable-sharing problem properly, then that commit r18202 can be reverted, and
>
> Agreed. Someone with enough motivation for Windows DLLs?
Actually, unless I'm much mistaken, r18202 can be reverted before solving the
variable-sharing problem properly, because it isn't solving it at all at the
moment. Ivan, do you agree? If so, will you do that, please?
> > the problem of how to name and describe the XML-name function goes away. That
> > would be good because we've no reason to want such a function in our public
> > API, as far as I know.
> >
> Other clients could find it useful to be able to validate a property
> name, but let's not add a public API for that weak reason:-)
Right.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 18 00:46:48 2006