[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Minutes of the tele-conference CIQ meeting held on 15 January 2001
Hi all > -----Original Message----- > From: Vincent Buller [mailto:vincent@and.nl] > Sent: Friday, February 02, 2001 2:01 AM > To: 'Ram Kumar'; ciq@lists.oasis-open.org > Subject: RE: Minutes of the tele-conference CIQ meeting held on 15 > January 2001 > > > Ram, all, > > > > > Vincent, I have enclosed the updated NAML version. > > Thanks! I will have a look at it soon. WOuld you care to also > send the DTD > itself? It is enclosed now. Sorry, I missed it earlier. > > > > we agreed during the meeting that for some of the terms used > > in the Global > > address > > spec., we are not sure what it means as the document was not > > complete and we > > agreed > > that we will have more examples from your people who > created the dtd. Let me create this comparision table first and then let us discuss the issues that we could have overlooked in december. > > I have sent you guys updated documentation of our GlobalAddress > specification, and I welcome any comments. I am using this doc. to create the table. >My worries though > are related to > timelines and creating unnecessary interdependencies. Inserting the > GlobalAddress spec into NAML does NOT depend on getting more > sample data - > we work with the spec all the time, and the level of documentation is > similar to what I've seen for NAML. If we agree to that we're fine. > > What I said in December is that I acknowledge the need for > people unknown to > the Address field of work, unlike you and me, to have > real-world sample data > to increase the level of trust they have in the structure's ability to > express real-world data. All I'm saying now is that getting > these samples > may take some time, and we should not let our progress depend on that. OK > > > > What we talked about at our kickoff meeting is to make an > extensible > > > multilevel definition. For example, for Address this would > > > mean that one > > > should be able to markup a street as a whole > > (street&premise:"prinses > > > julianastraat 26") or in parts (street:"prinses julianastraat", > > > premise:"26"). This is a next step that we can start > discussing now. > > Sorry guys, I may have misled you. Looking at my notes from > the kickoff > meeting we did not even plan to do this for V0.5! Quote: > v0.5 > - First integrate MSI and AND work, start 1st week of Jan 2001 > - Release first draft xNAL and xCIL (DTD and documentation), > 31st March 2001 > - Public comments by 30th April > - Review and integration 15th May, release 0.5 > > v1.0 > - Multilayer address bit > <================================================================ > - Extensible customer information > - Preliminary date: Public review August 15th 2001 > - Comments by Sept 30th > - Release Oct 31st > > v1.1 > - Internationalization, de-westernization > > > > > > > I am currently converting the GlobalAddress DTD to the latest > > > W3C schema > > > definition; this allows us to be more expressive as we > discussed in > > > December. Ram, did you look at XML Schema and can you have a go at > > > converting your specification? > > > > > > > I think we said that we will have an XML Schema for XNAL and > > XCIL in version > > 2.0 > > and not in this version. We have to be very careful when > > defining the Schema > > for > > names and addresses and in fact other customer data as the > size of the > > fields > > varies from country to country. For example, street names and > > person names > > are extremely large in Asian countries like India, > Srilanka, etc. For > > example, > > my full name is: PARUVACHI VENKATACHALAM RAMKUMAR > > Do you mind if we just keep calling you Ram? ;-) No worries! > > I could not find any reference to using schema in my notes, > but I remember > is that you would have a look at Schema to see if you could > easily switch. > If so, we'd use it, otherwise not. May be once, we have the common dtd for XNAL, then we can switch over to schema. > > By the way, using XML Schema does not enforce you to use all > the expressive > power; in other words, your samples of having to define field > lengths is not > a requirement for using schemas. It is possible to use XML > Schema as the > language, yet define nothing more or less than with a DTD. > > I would still like to use schema for this version; it's not that hard. > However, if you still feel it takes too much time or it increases > uncertainty too much we could save it for the next version (1.0 in our > December numbering). > > An introduction to Schema which helped me to get started: > http://www.xml.com/pub/a/2000/11/29/schemas/part1.html > > > > > > > Ram, did you hear anything from the DocBook people on the > > > e-mail you sent > > > them? > > > > I sent a couple of e-mails to Norman Walsh of the DocBook and > > have not heard anything so far. > > Well, it's in their interest too. I don't think we have a lot > of time to > spare :-) > > > > BTW, Bad Husick of Vignette, who was leading the CPEXchange > > group has left the group as he resigned from Vignette. > > That doesn't simplify things either.... I would have loved to > hear from them > what has happened to CPExchange's privacy policy being > questioned.... Does > Karl know? > > Cheers, > Vincent > Cheers Ram
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC