The MathML 2.0 Specification Last Call draft received a lot of comments. Most were noncontroversial, and we have done our best to accommodate them. Some involved more substantive issues, and provoked a good deal of discussion between the Math WG and the originators of the comments. In most cases, a consensus opinion emerged, but in others, minor differences or open problems remain.
Below we itemize the comments received and the Math WG responses. The dispositions of noncontroversial comments and suggestions are noted briefly in this document. In the case of more substantive issues, discussion is given below describing the background and the resolution proposed by the Math WG.
Bidirectional Layout of Math


Summary:  A proposal was made to add support to MathML for full, hierarchical, bidirectional layout, beyond the inherent Unicode support for bidirectional layout within elements accepting character data as content. 
Submitted:  Martin J. Duerst, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0147.html (W3C Member URI) 
Discussion: 
Inquiries to educators and researchers in righttoleft (RTL) writing communities determined that while practice is not uniform amngst these communities, bidi math layout may be significant in some of them, most notably in some Arabicspeaking locales. Further, it was pointed out that MathML 1.0 was not scrutinized from the I18N viewpoint, and consequently some discussion about bidi layout is necessary in MathML 2.0, even if it is mostly negative in nature, explicitly deferring some aspects of bidi layout to future version. After much discussion, a strong case emerged that the general problem of automatic bidi layout algorithms for math are difficult and complicated, due to the 2dimensional nature of math notation, and the fact that spatial relationships and juxtaposition frequently carry meaning in specific math notations. That, together with the lack of clear uniform practice in RTL language communities on which to model algorithms, led to the conclusion that automatic bidi layout in MathML would be deferred pending further investigation. At a minimum, the issue of manual bidi layout should be addressed in a future version of MathML. 
Resolution: 
A new section on bidi layout has been added to Chapter 3, specifying that the implicit part of the Unicode bidirectional algorithm is applied within leaf nodes, and specifying that MathML 2.0 does not address bidi equation layout in general. 
MathML Character Issues


Summary:  Several interrelated issues concerning MathML Characters have been raised. There is a question as to how to present the tables of MathML characters in Chapter 6, especially those characters whose Unicode code points are still provisional. There is also an issue about the role of Unicode Plane1 characters, such as "math bold italic x" and their relation to 'styling' mathematical text. Finally, there is some confusion about the nature of character data allowed in MathML token elements. (See also related issues on style attributes, the mglyph element and the defunct mchar element, and bidirectional layout.) 
Submitted:  Martin J. Duerst, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0147.html (W3C Member URI) 
Discussion: 
The MathML character issues proved to be quite serious and involved, affecting a number of W3C activities, as well as work of the Unicode Technical Committee. The first aspect of the problem is that a number of MathML characters, including some that are vital to the design of MathML such as ⁢ and &Applyfunction;, will not officially be in Unicode by the time the MathML Recommendation is likely to appear. However, since the MathML uses entity names extensively (see the discussion of <mchar> below for discussion of why this is so) the MathML DTD must point to something in declaring entity names. A wide variety of solutions was considered: publishing two DTDs, one using PUA codepoints, and one using the tentative assignments, publish an incomplete or invalid DTD, etc. However, in the light of
it was ultimately agreed that the MathML spec would continue to publish character tables and a DTD incorporating the provisional codepoints. But, Chapter 6 now goes to great lengths to identify the provisional assignments (color coding, text), to warn implementors of the possible risk of relying on the assignments, and to admonish them to be prepared to change their implementations should the final codepoint assignments change. A second thread considered what the role of proposed Unicode Mathematical Alphabetic Symbols should be in MathML. These characters represent various alphabetics used as symbols, such as "bold italic x". They are still provisional, but only one step away from adoption in Unicode 3.1. They are quite desirable from the point of view of MathML in that they
However, they also cause problems in that
To address these drawbacks, it was ultimately agreed that MathML would provide a markupbased interim encoding using a mathvariant attribute. Certain MathML token elements containing a single BMP character with particular mathvariant attribute values are defined to be canonically equivalent to the same token elements containing the corresponding Mathematical Alphabetic Symbol. This leads to exactly two representations for these characters, but the correspondence can be simply and precisely defined. This is done in Chapter 6. 
Resolution: 
We had several discussions with both members of the I18N WG and of the
Unicode Technical Committee. They suggested suitable formulations of
caveats and descriptions of the situation visavis Unicode and ISO
10646. Chapter 6 was completely rewritten, and the character tables
were extensively redesigned. Explanatory text was also added
elsewhere in the spec to make sure that the proper usage of character
data in MathML is clear, and that the official status of characters is
also clear.

Summary:  Various technical errors in the MathML character tables 
Submitted:  Roger Sidje, http://lists.w3.org/Archives/Public/wwwmath/msg00775.html
Neil Soiffer, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0175.html (W3C Member URI) Neil Soiffer, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0252.html (W3C Member URI) Robert Miner, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0149.html (W3C Member URI) 
Discussion:  After the substantive issues discussed above were
resolved, correcting the substance and improving the presentation of
the character tables was straightforward. 
Resolution:  Done. See the new tables. 
Corrections and Additions to the MathML DOM


Summary:  DOM should be defined to be normative 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion:  We agree that this should be done. 
Resolution:  The MathML DOM is now normative. 
Summary:  MathML DOM needs to define an IDL package. 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00812.html Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00823.html 
Discussion:  It is agreed that IDL, Java, and ECMAScript packages
should be prepared. 
Resolution:  These have been added. 
Summary:  MathML DOM should use DOM Level 2 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion:  In fact, DOM Level 2 is used throughout. There was one
reference to DOM Level 1, which was in error. 
Resolution:  The reference has been changed to DOM Level 2. 
Summary:  A number of technical and typographical corrections, especially in Appendix E. 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html
Susan Lesch, http://lists.w3.org/Archives/Public/wwwmath/msg00782.html 
Discussion:  These should be repaired. 
Resolution:  All of the technical and typographical errors pointed out have been
fixed. 
Summary:  The MathML DOM should define a "hasFeature" string. 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion:  This will be done. 
Resolution:  The string "org.w3c.dom.mathml" will be used. A paragraph stating this
has been added to Chapter 8. 
Summary:  Statements in Chapter 8 regarding the DOM Level 2 support for "cascaded, computed or actual style values for a specific element" are incorrect. 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion:  This is entirely true. These statements will be removed. 
Resolution:  Chapter 8 now contains no reference to DOM style support.. 
Summary:  A statement in Chapter 8 that the MathML DOM encodes syntactical restrictions imposed by MathML was questioned. Since the Core doesn't provide any syntactical restrictions, how can this statement be enforced? 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion:  The MathML DOM uses Core DOMExceptions  in
particular, the HIERARCHY_REQUEST_ERR  to enforce certain of these restrictions.
Additionally, some differences in the types of attributes and method parameters defined
in the various MathML DOM interfaces may be seen as enforcement. 
Resolution:  In the absence of further comment, the statement will be left as is. 
Summary:  The MathMLDOMImplementation method for creation of a toplevel MathMLmathElement
(corresponding to the toplevel <math> element), rather than using a
"MathMLDocument::create" method, was questioned. Also, the "parent" parameter to
this method is unnecessary. 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion: 
Agreement on the "parent" parameter. This has been deleted. The use of MathMLDOMImplementation to create a MathMLmathElement is
predicated on the expected primary usage of MathML as embedded in
documents of other types, but always inside a toplevel
The entire issue of interaction between differing DOM implementations representing sections of a single document is unresolved at this point. We feel that some separation of factory methods from the Document interface may be part of the ultimate resolution; the issue is being studied currently. Since the MathML 2.0 specification is intended to remain stable for some time after promulgation, there is a concern that some hook which could play the role of accessing factory methods without a Document interface might allow a reasonable interaction between implementations of the MathML DOM and ambient DOM implementations. 
Resolution: 
For the time being, this functionality, and the

Summary:  The MathMLDocumentFragment interface should not be derived from MathMLElement. In particular, it should have no style, class, or id attributes. Its use in readonly attributes to return certain child Nodes of other interfaces is felt to be inappropriate, as a child Node of a MathMLDocumentFragment could not be simultaneously a child of another Node. 
Submitted:  Lauren Wood, http://lists.w3.org/Archives/Public/wwwmath/msg00760.html

Discussion: 
It is agreed that this should not derive from MathMLElement. Also, the disputed usage of this interface is indeed at odds with the spirit of DocumentFragment. 
Resolution:  The MathMLDocumentFragment interface is now derived simply from the
DocumentFragment interface. The usage as a container for children of other Nodes
has been moved to the new interface MathMLNodeList, derived trivially from NodeList
but intended to contain MathMLElement Nodes and Text Nodes only. 
Typographical and Editorial Corrections


Summary:  A number of minor editorial corrections and suggestions 
Submitted:  Susan Lesch, http://lists.w3.org/Archives/Public/wwwmath/msg00782.html

Discussion:  David points out that the use of 'lower case' and 'upper
case' instead of 'lowercase' and 'uppercase' was done for
compatibility with old ISO specifications. Apart from that, we will
take Susan's suggestions. 
Resolution:  Done. 
Summary:  Two technical errors in XSL examples in Chapter 5 
Submitted:  Sharon Adler, http://lists.w3.org/Archives/Public/wwwmath/msg00785.html

Discussion:  Not controversial. 
Resolution:  Done. 
Summary:  Numerous proofreading errors, editorial suggestions, and references 
Submitted:  Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00793.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00795.html Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00807.html Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00822.html Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00828.html Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00829.html Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00843.html Stephane Dalmas, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0121.html (W3C Member URI) 
Discussion:  Mostly of the proposed changes were noncontroversial,
though a number involved editorial policy decisions. Thus in some
cases, we opted not to take the suggestions. 
Resolution:  Mostly done. 
Summary:  New internet media type for MathML 
Submitted:  Murata Makoto, http://lists.w3.org/Archives/Public/wwwmath/msg00831.html
Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00839.html 
Discussion:  We monitored the discussion on XML MIME type standards and
have modified the text to reflect the latest information available. We also
put in a warning that the MIME type given is not yet a standard, and
thus implementors must be prepared to change in the future if
necessary. 
Resolution:  Done. 
Mixing math and natural language


Summary:  Rendering of some content markup is language dependent. 
Submitted:  Andreas Strotmann, http://lists.w3.org/Archives/Public/wwwmath/msg00714.html
Martin J. Duerst, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0147.html (W3C Member URI) 
Discussion: 
The names of the elements are completely separate from how such
content elements, and/or their applications is displayed. The sample
renderings for content elements are just that, sample renderings.
It is perfectly appropriate for the sample renderings in another
language to be localized by using different vocabulary.

Resolution:  Make it clearer in the discussion that the sample
renderings of content elements can be localized. 
Reservations about the mchar element


Summary:  The mchar element was introduced in MathML 2.0 so that MathML instances using 'MathML characters' could be wellformed without a DTD. In part, this was done to facilitate use with XML Schemas. Objections that this move is premature and hard to implement were raised in several quarters. 
Submitted:  Roger Sidje, http://lists.w3.org/Archives/Public/wwwmath/msg00771.html
Martin J. Duerst, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0147.html (W3C Member URI) Dan Connolly, http://lists.w3.org/Archives/Public/wwwmath/msg00763.html Dan Connolly, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0063.html (W3C Member URI) 
Discussion: 
In light of the widespread objection to the proposal, we put the
question of named character entities in MathML first to the XML Schema
group. They opted not to decide the issue, since it would involve
changes directly to XML. However, since the problem also affected
other groups, notably HTML, we then put the issue before the W3C Team.
Ultimately were told that we should stick with entities for now,
in spite of the drawbacks.

Resolution:  The mchar element has been removed in the
proposed Candidate Recommendation, and a discussion of the issues
surrounding 'DTDless' usage of MathML has been added.

Miscellaneous Content Markup Issues


Summary:  A request that inverse hyperbolic trigonometric functions to be prefixed with 'ar' instead of 'arc' on philosophical grounds. 
Submitted:  Leszek Sczaniecki, http://lists.w3.org/Archives/Public/wwwmath/msg00780.html

Discussion:  A quick double check of mathematical reference works
strongly reinforced the Math WG's position that, philosophy aside, the
'arc' prefix is the standard and widespread convention. 
Resolution:  No change. 
Summary:  Proposal to change 'definitionURL' to 'definitionURI' 
Submitted:  Pankaj Kamthan, http://lists.w3.org/Archives/Public/wwwmath/msg00793.html

Discussion: 
While it is true that the intended values of this attribute are URI's,
there are also backward compatibility issues. The attribute name
definitionURL was used in MathML 1.0. If we were to change the name
of this attribute, applications would still need to support both
during the period in which definitionURL was deprecated, causing
additional compatibility issues.

Resolution:  Leave the attribute name as definitionURL. 
Summary:  Issues with quantifiers in content markup 
Submitted:  Andreas Strotmann, http://lists.w3.org/Archives/Public/wwwmath/msg00674.html

Discussion: 
On reviewing this issue it quickly became clear that restricting the
use of named arguments to the already defined elements that understood
them was too restrictive. In particular, it prevents users from
making use of the named arguments such as <bvar> when defining
their own extensions to MathML for purposes of, say, specialized
quantifiers.

Resolution:  Allow named arguments ( "qualifiers" ) in all <apply>
constructions, subject only to the restriction that such usage be
correct only when the definition of the function being applied takes
into account such usage. Note that such definitions may be provided
by the user through use of a definitionURL and/or
<csymbol>s. 
Summary:  Big Onotation and related asymptotic concepts 
Submitted:  David Eppstein , http://lists.w3.org/Archives/Public/wwwmath/msg00683.html

Discussion: 
The request for additional builtin functions supporting these
important concepts in asymptotic analysis was carefully
considered. (1) The public list discussion and discussions with in the
working group made it clear that there was no quick consensus on the
best way to introduce the concept. (2) The functionality was on the
edge of the stated K14 domain. (3) The existing extension mechanism,
based on providing a definition for a <csymbol> object, is
adequate to gain experience with any of the possible approaches,
perhaps leading to explicit support in a future extension to MathML.

Resolution:  It has been decided not to include additional functions
for asymptotic analysis at this time. 
Summary:  Some confusion about the proper definition of moments, gcd etc. 
Submitted:  James Davenport, http://lists.w3.org/Archives/Public/wwwmath/msg00687.html
William F. Hammond, http://lists.w3.org/Archives/Public/wwwmath/msg00718.html 
Discussion: 
The discussion surrounding gcd involved two points. (1) The name "gcd" is language specific. (2) There are a number of gcd concepts depending on the mathematical domain one is considering. Alternative gcd definitions can be accommodated by use of definitionURL and/or <csymbol>. The discussion regarding moments was triggered by the fact that the definition depends on the point about which the moment is computed, e.g., central moments. It was noted that the name of an element need not have anything to do with how it is displayed (visually or aurally). The idea emerged that a new qualifier capturing the concept of "moment about" was in order. 
Resolution:  Add a new qualifier element, <momentabout>, to describe
how the moment is to be considered. There is a default behavior for
when this qualifier is not explicitly used. The qualifier can specify
concepts such as "moment about the mean" by specifying the function
used to compute the point ( e.g., <mean/*>) as the argument to
the qualifier. 
Summary:  Proposal to add some missing constructs 
Submitted:  Andreas Strotmann, http://lists.w3.org/Archives/Public/wwwmath/msg00716.html

Discussion: 
This discussion looked at a number of concepts that potentially needed
explicit representation. They included: 1) the notion of application.
Does this need a new element, or can an empty <apply> be used? 2)
Cartesian product. Should an operator exist explicitly for this, or
is it handled by applying <times/> to two or more sets? 3) Use
of vectors orlists to represent ntuples. Do we need an explicit
"tuple" container? 4) mechanisms for referring to a set, list,
function, quantifier, predicate as concepts. These concepts do not
have a default rendering, but could well be regarded as within the
vocabulary of MathML for K13.

Resolution:  1) and 4) The need for noun forms of these various
mathematical constructs mentioned here (all containers in MathML) is
genuine in the same way that the need for a noun form for a function
was needed separate from application of that same function to 0
arguments, but was viewed as quite specialized in that no algebra of
such objects is generally dealt with in K13. If explicit
representations are wanted in some context, they can already be
represented by use of <csymbol> with appropriate definitionURL's. Thus
the working group has elected not to introduce any new elements to
explicitly represent the noun forms of these containers. 2) Cartesian
product is adequately represented by applying the <times>
operator to two or more sets and this is to be made explicit in the
signatures in Appendix C. 3) It has been decided to continue to use
lists and/or vectors to represent ntuples at this time since whenever
the standard definitions of a list (or vector) are inappropriate, the
simple act of adding a definitionURL can be used to transform them
into an appropriately defined object. 
Style Attributes on Presentation Token Elements


Summary:  A proposal was made to remove or deprecate the 'style' attributes on presentation token elements.  
Submitted:  Daniel Dardailler (reposted by Angel Diaz), http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0138.html (W3C Member URI) Hakon Lie, http://lists.w3.org/Archives/Public/wwwmath/msg00771.html Daniel Dardailler (reposted by Angel Diaz), http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0217.html (W3C Member URI) 

Discussion: 
MathML 1.01 allowed 'fontfamily', 'fontweight', 'fontslant', 'color' and 'background' attributes on presentation token elements. The MathML 2.0 last call draft made no change in this regard, and also permits these attributes. After some analysis, the Math WG has concluded that these attributes were being overloaded to carry both semantic and style information. We propose a remedy that attempts to separate these functions to preserve the semantic usage while improving compatibility with CSS styling in CSSaware environments. The main problem is that mathematics treats style information for single character symbols in a completely different way than style information works with text. In mathematics, fraktur g and bold g are two distinct symbols, and not the same character styled in two ways, just as an 'alpha' is not a styled 'a' in either mathematics or text. Preserving the conventional usage and meaning of these typographically distinguished symbols is important for MathML. Moreover, because typographically distinguished symbols carry meaning in mathematical expressions, encapsulating the description of these symbols directly in MathML markup alone is a requirement for MathML. It is essential for interoperability in a variety of nonCSS aware systems. Recent developments concerning mathematical characters in Unicode are another important factor in the discussion. Since there has long been difficulty in mathematical publishing distinguishing between a "styled character" and a "typographically distinguished symbol", major science and technology publishers mounted a multiyear campaign to have special Unicode characters allocated for typographically distinguished characters. This effort was successful, and it is now essentially definite that in Unicode 3.1, there will be 13 runs of these alphabetic symbol characters in Unicode Plane 1. At that point, there will be code points for characters such as "math bold italic x" and "math fraktur g". The Math WG strongly supports the use of these new characters, and feels that MathML 2.0 should provide a transitional markup equivalent for these new characters for use until there is widespread support for these new characters in processing applications and fonts . Finally, it is also true that certain presentational attributes of mathematical equations really are generic 'style information' in the CSS sense. For example, the base font and base point size for an entire equation can be changed without risk of information loss. For accessibility, and for reasons of improved information management, it is desirable to distinguish these meaningneutral presentation properties from the presentational properties of typographically distinguished symbols. The Math WG proposes the following remedy, which we believe addresses all of the issues raise above.


Resolution:  New material has been added to Chapter 3 (presentation
markup) introducing the new mathematical style attributes, and
explaining their use and meaning. A new discussion of Unicode
revisions and the Plane 1 mathematical characters has been added to
Chapter 6 (MathML characters), along with definitive character tables.
A new section has been added to Chapter 7 (interface issues)
discussing issues related to using CSS with MathML, and a sample style
CSS stylesheet has been added as an Appendix. 

Test Suite and Validator Links


Summary:  There were several enquiries as to why links to the MathML test suite and validator aren't active. 
Submitted:  Luis Alvarez Sobreviela, http://lists.w3.org/Archives/Public/wwwmath/msg00783.html
'Ariel', http://lists.w3.org/Archives/Public/wwwmath/msg00833.html 
Discussion:  The test suite and validator are the subject of ongoing
development by working group members and other members of the MathML
community. Since both of these applications require a good deal of
web development, the people doing the work concluded that it wasn't
effective to try to work directly on the W3C servers. Consequently,
work will proceed on various external Web sites, but the spec will
point to place holder pages under www.w3.org/Math, which will in
turn refer readers to the most up to date versions of the test suite
and validator. As stable versions of the test suite and validator
become available, the intention is to move them to the W3C servers.
A preview version of the test suite is already available in the
Members area.

Resolution:  Place holder pages have been installed at http://www.w3.org/Math/testsuite
and http://www.w3.org/Math/validator.
Work on the actual test suite and validator is ongoing, but
substantial progress has been made. We anticipate replacing the
placeholders during the CR period.

Summary:  Suggested improvements to the test suite 
Submitted:  Vincent Quint, http://lists.w3.org/Archives/Member/w3cmathwg/2000AprJun/0060.html (W3C Member URI) 
Discussion:  Vincent Quint suggested a number of
noncontroversial improvements. 
Resolution:  They are being incorporated as time and resources permit. 
XSL Processing


Summary:  A suggestion was made to reverse the roles of ids and xrefs in the crossreferences mechanism described in Chapter 5 of the MathML 2 specification for performance reasons, since ids are typically indexed while xrefs are not. 
Submitted:  Sharon Adler, http://lists.w3.org/Archives/Public/wwwmath/msg00785.html

Discussion: 
The changes suggested in Comment 1 (on editorial errors) have been applied in the Candidate Recommendation. The second comment relates to the order of "id"s and "xref"s in parallel markup. The observation was that this crossreferencing scheme could be computationally intensive if one had to follow links in the "wrong" direction, and asks whether some additional restrictions should be imposed, or the direction of the links reversed. This is potentially an issue, depending on the implementation. It is important to realize that the application is free to choose which branch receives the "id"s and which branch has the "xref"s. This allows applications to follow the practice suggested in the email, and to put the links in the other direction if it chooses. This is noted in the fourth paragraph from the last in the current section 5.3.3. It should also be noted that since there may be more than two branches in a <semantics> element, these crossreferences may be multiway associations and there is more than the question of choosing one direction or the other. Finally, for computationally intensive tasks on intricate linkings an application may choose to use any of the various mechanisms of XLink internally within the MathML object. 
Resolution: 
The comments from the XSL group have all been addressed in new text in Chapter 5. 
Copyright 2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability,trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.