[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [legalxml-econtracts] grammatical paras necessary for "linkingand retrieval mechanisms"?
John McClure wrote: > Hi Jason, > Sorry that my explanations weren't clear. > (snip) > > Because a grammatical paragraph exists conceptually then software needs to be > able to reference it It doesn't follow from the mere fact that it exists conceptually that it needs to be marked up. For example, nobody has suggested so far that we mark up sentences, even though they to exist conceptually. The only reason to mark something up is if the markup will be used, and the cost of doing the markup does not exceed the benefits. > for libraries (e.g., as the subject of reuse) Example, please. I'm embarking on an analysis of the Hanover Lease but i won't have a chance to report back until after Thanksgiving. So, if you have any examples of how grammatical para is useful, i'd love to see them. , for display > (e.g., as the subject of widow processing, cursoring control, and text selection > highlighting), and for metadata (as the subject of RDF statements). Like any > other identifiable "thing" in a contract, they need to be accessed using an <a> > anchor tag. Why isn't it enough to be able to refer to its enclosing item? (Example please) : > > With regard to samples, that which you provided in the Appendix is good enough. No, its not a contract. I'd like to see a grammatical para in a contract which you'd like to re-use, so i can understand why item re-use is insufficient (coupled with simple para re-use if nece). > With regard to the lack of guarantee that a grammatical paragraph fully > encapsulates its content, well, I am interested in a standard that works, when > used correctly. When used incorrectly, well, that's their problem not mine. With > regard to who would (ever) want to link to a specific item of trailing content, > well, on the whole I agree with you that the argument of linking to trailing > content is not too compelling to me either. okay, i'm glad we agree on that important point. With regard to "poking at and > talking about" further examples, for me, well, I am at the end of my > participation in such exercise -- I know enough for my purposes to move on. i must say i would find your views more compelling if you were to show how they apply to sample contracts and/or are supported by examples from contracts. at the end of the day, its how our ideas apply to contracts which counts. > > I think it's a good thing for everyone in the galaxy that XHTML 2.0 introduces > the <section> element and redefines the <p> element from a simple paragraph to a > grammatical paragraph, for the record, i still don't see why its a "good thing". it might be, but its certainly not clear. it has some advantages, but the costs are considerable in terms of ease of authoring. the jury is still out on this. cheers, Jason and we should build on it as a very compelling base for > further standardization and easy, international, acceptance of our work. I hope > we can vote about this soon. > > Thanks, > John > > -----Original Message----- > From: Jason Harrop [mailto:jharrop@speedlegal.com] > Sent: Sunday, November 23, 2003 4:28 AM > To: Legalxml-Econtracts > Subject: Re: [legalxml-econtracts] grammatical paras necessary for > "linking and retrieval mechanisms"? > > > John McClure wrote: > >>Jason, >>I said for "linking and retrieval mechanisms" because if a link is to be made > > to > >>a trailing fragment of a grammatical paragraph, using a logical XP expression >>that does not rely on id-lookup, then that fragment needs to exist physically > > as > >>a part of that grammatical paragraph. > > > ?? > > In the simple para model, the xpath > >>expression to that fragment simply cannot be stated without using #id. > > > Incorrect! Though without the example i've asked you for, i fail to see why > you'd want to link to the "trailing fragment of a grammatical para" anyway. > > That's > >>the flaw of the simple para model: it does not encapsulate content as one > > might > >>normally expect, > > > Not that there's any guarantee the content will be so encapsulated (with either > the grammatical para models which have been proposed in the TC, nor with XHTML > 2.0) > > and hence it's not possible to reference the data logically -- > >>you're left with #id references, which I find unacceptable for > > previosuly-stated > >>reasons. > > > ?? > > > >>As for retrieval mechanisms, if I want to retrieve the entire grammatical >>paragraph, that's simply not possible with the simple paragraph model because >>one can't know apriori the extent of SIBLING elements that are to be retrieved >>as part of the grammatical paragraph that is to be retrieved. > > > Very true, but please show me a compelling example with one of our benchmark > contracts as to why you'd want to store/reuse a grammatical para, rather than an > item. > > Examples please, so we have something we can poke at and talk about. > > thanks > > Jason > > > > >>Hope that helps. Anyway, attached is a start of a module definition for the > > four > >>elements that I've mentioned. >> >><!-- LegalXML Element Structure >> >> <html> >> <body> >> <legal:instrument> >> <section/> >> <legal:layout/> >> <legal:attachment/> >> </legal:instrument> >> </body> >> </html> >> >> To do: >> (a) insert instrument, attachment, and layout into %body.content; >> (b) insert signature into %inline.content; >>--> >> >>>-----Original Message----- >>>From: Jason Harrop [mailto:jharrop@speedlegal.com] >>>Sent: Saturday, November 22, 2003 1:25 PM >>>To: Legalxml-Econtracts >>>Subject: [legalxml-econtracts] grammatical paras necessary for "linking >>>and retrieval mechanisms"? >>> >>> >>>I think grammatical paragraps ARE a >>> >>> >>>> key requirement for linking and retrieval mechanisms. ... it >>> >>>encapsulates >>> >>> >>>> content that can be further analyzed by specialized software. >>> >>>Please provide examples which substantiate your claim. Examples from the >>>Hanover Lease or any other contract would be fine. >>> >>>thanks >>> >>>Jason >>> >>> >>>To unsubscribe from this mailing list (and be removed from the roster >>>of the OASIS TC), go to >>>http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/member >> >>s/leave_workgroup.php. >> >> >>------------------------------------------------------------------------ >> >>To unsubscribe from this mailing list (and be removed from the roster of the > > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_w > orkgroup.php. > > > > To unsubscribe from this mailing list (and be removed from the roster of the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_w > orkgroup.php. > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/leave_workgroup.php. > > > -- Jason Harrop CTO, SPEEDLEGAL jharrop@speedlegal.com Melbourne Mob +61 (0)402 02 66 34 Tel +61 (0)3 9670 0141 Fax +61 (0)3 9670 0142 www.speedlegal.com SmartPrecedent(R) software The most intelligent way to create documents
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]