[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: eContracts draft minutes 21 Dec 05
Hi Zoran, The open items refer to the points in my email to the list on 28/10/05 with subject "Development steps for TC specification - revised". I hope you can join us. Regards Peter > -----Original Message----- > From: Zoran Milosevic [mailto:zoranm@fastmail.fm] > Sent: Monday, 26 December 2005 6:11 PM > To: 'Dave Marvit'; dang@media.mit.edu; 'Rolly Chambers'; > 'Peter Meyer'; 'Dr. Laurence Leff' > Subject: RE: eContracts draft minutes 21 Dec 05 > > > Hi All, > > Hope you all had enjoyable Christmas! > > I have been unwell over last couple of months (had some > cluster headaches > which started reoccurring after some 8 years of headache free > period). They > result in very strong pain and this was a reason I was unable > to participate > more. I am hoping to join you tomorrow but am not sure what > these 'open > items' are referring to. Would anyone be able to remind me > about these? > > Cheers, > Zoran > > > > Once again, would someone mind posting this to the list for me. > > > > Thanks, > > -Dave > > --------------------------------------- > > Draft Minutes December 21, 2005 > > eContracts TC > > > > In attendance: > > Dan Greenwood > > Dave Marvit > > Rolly Chambers > > Peter Meyer > > Dr. Leff > > > > Dan: We are hopeful that we can keep working on > > the list of open items, working it down to no > > open items, and call the schema 1.0 when we are down to no > open issues. > > > > So, how many open items do we have left? > > > > Peter: We got to 1.3 and are looking at 1.4. > > > > [Consensus is reached on using URNs for the > > namespace instead of URLs to avoid confusion > > among end-users who think that they can click on a URL and > go to a web > > page.] > > > > 1.5 agreed that we can't do much on 1.5.1a > > because it depends upon other schemas. > > 1.5.1b - We can incorporate terms that we need. > > We can look to UBL and vCard. (Rolly believes > > that there is an XML version of vCard.) So the > > issue is to define what do we actually need and > > then look for sources for that markup. > > > > Rolly: I agree and I think we should look to that > > as a next step after we have the structural piece. > > [Consensus is reached on that issue]. > > > > Dan: In the release that comes out with our > > standard we should have some statement about how > > we will address this issue. I agree that it > > should be out of scope but people should be aware > > that we are thinking about it and give them some > > guidance as to how it will play out. > > > > Peter: I agree. > > > > Rolly: Technically there is a mechanism, the ANY > > model. This opens up the schema where elements > > from any other schema can be plugged in without > > raising validation issues. We might leave it as > > 'ANY' initially and then restrict that hole down the line. > > > > Peter: 1.6, file organization - I think this is > > just a question of familiarity. We may be able to > > simplify the file organization when we remove the > > document type so we only have contract, but that has a price. > > > > Dr. Leff: I think that we should allow support > > for other document types but we should also have > > a pre-established form without the need for > > customization for people who just want to do contracts. > > > > Peter: In effect that's what we have done. The > > Relax is the development tool. The XSDs and DTDs > > are the working tools for day to day > > applications. If they want to customize then they go back > to the Relax. > > > > [no argument there] > > > > Rolly: I agree. I was just hoping that we could > > clarify things because I could see the parts but > > I couldn't see how to put them together. > > > > Peter: Yes, we need a better description of how > > to use this. I agree that this is an important > > part of getting people to use it. This does need > > to be part of our base implementation and our base write-up. > > > > Section 2: > > > > Peter: In section 2 we are getting down to the > > nuts and bolts. First, do we want to change any > > of the element names? Rolly had suggested a > > number of changes. (This ties in to 2.5 as well > > with discussion of the 'item' element in lists might be confusing.) > > > > Rolly might have suggested changing 'item' to > > 'section'. There is no right and wrong about > > this. [Peter explains his reasoning for 'item' as something entirely > > generic.] > > > > Dr. Leff: We should note that we will not allow > > an item within an item within a block. > > > > Peter: So, the question is if Rolly is convinces by the reasoning. > > > > Rolly: I don't fault the reasoning. But even with > > that said, item is being used in two different > > ways. I am not keen to shoot down what you have without having an > > alternative. > > > > Dr. Leff:: I think we need an implementation to > > really see. Experience will reveal many issues and solutions. > > > > Rolly: It's the semantics. Item connotes to me a > > list item. And seeing it used in two different contexts is > confusing. > > > > Peter: We grappled with this very issue. > > Ultimately we felt that using clause or element > > of other equivalent was more of a problem. That's > > why we stuck with item for everything. > > > > Dave: It sounds like Peter came to the same > > conclusion as Rolly - it would be better if we > > had a different name but we don't have one. > > > > Peter: So at this stage we will proceed with the structural > model as in > > BNML. > > > > Rolly: OK, but if someone comes up with a better > > term they should let us know for consideration. > > > > Dan: It might be worth noting that the TC has had > > an extensive discussion on 'topic' at some point in the past. > > > > Rolly: In 2.1 I was suggesting that instead of calling it > text we call it > > line. > > > > Peter: I understand that. The drawback is that > > people might think it represents a printed line, > > it might refer to the way the text is being rendered. > > > > Rolly: But it has a break after it. Why would > > you define it as a line if it didn't have a break > > after it? I would suggest that we define 'text' as a string of text. > > > > [Concensus] > > > > Dan: Good. Anything else? > > > > Rolly: All we had left was changing adjunct to > > attachment. One of these changes between Australian and > American English. > > > > [Peter discusses distinctions between container > > names. Dave notes that 'attachment' has expanded > > its meaning because of its usage in email.] > > > > Dan: I'd propose that we keep this on the list of > > things that we may change. Then we can make a > > final decision in the context of what else needs to be changed. > > > > [agreed] > > > > Meeting adjourned. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]