OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

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

Subject: minutes from ER teleconference 20001211

Present: Lauren Wood, Norm Walsh, John Cowan, Tony Coates, 
Paul Grosso
Observers: Terry Allen
Absent: David Leland

lower case vs camel case vs hyphens:
Tony suggests upper camel case for elements and lower for 
attributes. Norm thinks camel case is harder to type and good 
editors will take a while so he prefers lower case or hyphens. Paul 
isn't sure that people will edit catalogs in an editor. Lower case 
with hyphens is what CSS and XSLFO agreed on and it seems 
easier. Terry says camel case is more typing and it's prone to 
error. Lower case with periods would work. If these names are used 
as identifiers then they can't be used in Java. 

Do we want one style, or two (one for elements and one for 
attributes)? Tony wants two in camel case, but not in the hyphen 
case. John points out that the hyphen overloads the minus sign in 
most programming languages. John suggests, e.g., for an element 
Public-id and an attribute public-id to make conversion 
programming easier. 

Vote: first question: rule out all upper, all lower without punctuation: 
no objections.
second question: camel case vs punctuation: camel: John, Tony, 
punctuation: Norm, Paul

Camel case wins. Next question: John moves there should be a 
difference between elements and attributes:
Yes: John, Tony
no: Norm, Lauren, Paul

Shall they be upper camel case? Yes: nobody
No: Norm, John, Tony, Paul
abstain: Lauren

The names of elements and attributes shall be lower camel case. 
This shall not constrain extensions. 

Which document will we start with? John's XML Catalog, or TR 
Should we make normative reference to TR9401, or start with it and 
change it? For example, XML does not make normative reference 
to SGML. 
Motion: the ER specification should make normative reference to 
TR 9401: Yes: 
No: John, Tony, Norm, Lauren
abstain: Paul

Proposal to base the ER specification on TR 9401: Yes: Tony, 
Paul, Norm, Lauren
abstain: John

Proposal: We will express a subset of TR9401 in XML such that 
each catalog entry (e.g., PUBLIC, SYSTEM, DELEGATE) is an 
element and the entry contents are expressed as attribute values 
(e.g., public identifier, href). This is what John did in XML Catalog. 
No objections.

Proposal: The minimal subset of TR9401 semantics is PUBLIC, 
SYSTEM, DELEGATE, CATALOG, BASE and some extension 
No objections.

Proposal: that the semantics of TR9401 BASE be expressed not 
as an element, but using the methods of xml:base. 
No objections. 
One problem is that BASE semantics involve scope, or until the 
end of the document. We may need a grouping element, or to allow 
xml:base on every element. This should be an issue. 
John informally proposes that the root element be the grouping 
element, i.e., that it can be recursive (be a child of itself). Action to 
John to put this in email for discussion. 

Norm will construct a first draft (TR 9401 as it stands) and a 
second version (deleted extraneous matter). 

He will put them on the web site. He will also have a first draft of 
the web site done by the end of the week. 

http://www.oasis-open.org/committees/entity/index.shtml is our 
web site; note that it is public (as are our mail archives).

Next meeting is in four weeks since we don't meet on December 


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

Powered by eList eXpress LLC