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

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[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]