Group

Hello,

In the several drafts that i found, i've not seen the group feature like in the rfc2426. The groups aren't
supported ?

Regards,

--

-- 
Vincent

latest vCard DTD

Hi
Where do I find the latest version of the XML vCard DTD?

I have only been able to lacate the expired draft.

regards
---------------------------------
Anders H. Andersen
System developer
Mobilethink A/S
Arosgaarden
Åboulevarden 23, 5.sal
DK - 8000 Århus C
a.h.andersen <at> mobilethink.dk
Direkte tlf: +45 8620 7810
Telefon:     +45 8620 7800
Fax:         +45 8620 7801
------------------------------

Software engineer

Hi:

I have got your email from the Web site and I am very interested in working for your company. I 
have a BS in Electrical Engineering and computer science and worked on my Master degree 
in Telecommunication engineering (not finished due to the lucrative market!). I have also 7++ 
years of experience with software development, Internet development and hardware. I have 
worked for many companies both in Iran and in the United States using different development 
environments.
I am looking for a position which utilizes my experience. I am open to both Permanent position 
or contract to permanent positions.

I am Canadian resident and have permission to work in Canada.
I have attached my resume and sincerely appreciate your attention, thank you.

Sincerely,

Kian Haghdad

Here is my resume:
Kian Haghdad
8 Kingsbridge Crt., Apt. 508 
Toronto, Ontario M2R 1L5
Home: (416) 630-7066
Fax:  (416) 630-7991
Email: khaghdad27 <at> yahoo.com

I have more than 7+ years of experience in application development, Database Management, 
Internet development. I have also been involved in hardware design. My software 
development experience is mainly in Visual Basic, Visual C++, Visual J++, Visual InterDev, 
COM, DCOM, MFC, SDKs, MS-Access, MS-SQL, FoxPro,

A simple question

Hi!

In some articles writes that XML is a semistructured document, is that
true?.
If that is the case, what do they really mean?

Thank you
Handren Ahmed

Where is the DTD

Hello,

http://www.imc.org/draft-dawson-vcard-xml-dtd has expired.
Where I could find the last DTD?

Thx

Luc PUGEAT
______________________________________________________________________
Ukibi.com
Ma carte de visite a changé / Check my new calling card
 <at>  http://www.ukibi.com/luc.pugeat

May, 24th 2000- Ukibi awarded "BEST TOOL" at Internet World Berlin

P3P and vCard-in-XML

Dear Frank, time ago I was asking for information on vCard, for the W3C's P3P 
activity. P3P is now coming back on the vCard issue, and I'd need to go on with
the dialogue. The main point here is that P3P has now gone to "last call" status, 
which is the final status before it can actually become a world standard.
As you can check from the specification http://www.w3.org/TR/P3P , section 4
defines a simple schema mechanism which has many common points to vCard. 
In the design phase, we tried to keep the basic P3P schema as much compatible to 
vCard as possible (in particular, the P3P basic schema should be a direct 
subset of vCard, when similar fields are defined).
Anyway, the vCard-in-XML draft now has the effect that eventually there will be
two different standards for the definition of personal fields in XML. 
Although both easily mappable one into the other (and in general, to vCard), this
makes us wonder if there is the possibility of a deeper integration (if it's
worth). That is to say, can P3P and vCard-in-XML arrive to smooth differences
as much as possible (in the ideal case, be one)? Or this is simply not possible, 
or too late due to timeline factors? How much room is there for such an aligning?
I'd appreciate your opinion on this important point.

To this extent, feedback from companies that are going to support vCard-in-XML 
is also important. I know of the Microsoft's effort with Office 2000 (that Lisa
Lippert forwarded to us time ago). Are you aware of any other efforts?

Thanks, and hear you soon,
-Massimo

/---------------------------------------------------------------\
| Massimo Marchiori                    Room NE43-350            |
| The World Wide Web Consortium (W3C)  545 Technology Square    |
| MIT Laboratory for Computer Science  Cambridge, MA 02139, USA |

Canada Blower 11/99

Canada Blower now offers high pressure centrifugal blowers and 
blower systems for up to:

10,000 CFM  <at>  5 PSIG PRESSURE

We specialize in pressure blowers in series for unique performance 
range of HIGH PRESSURES together with HIGH TEMPERATURES 
- up to 1000 F.

Please visit us at http://www.angelfire.com/ms/blower and fill out an 
automatic inquiry form.

Susan Terlecki
Marketing Manager
CANADA BLOWER

Re: revised DTD

revised DTD

I've reworked the DTD to resolve some issues that have been raised. I
believe this represents an improvement on the first draft, please feel
free
to disagree.


Changes:
The attribute lang becomes xml.lang , the language attribute of
native XML.

The number of elements and entities that can occur many times has
been reduced. Although this does not form a truly identical XML
representation for vCard as specified in RFC 2426, it does form a more
meaningful representation of the data. e.g. you can only have one
first name, one family name, and one birthday.

The element n now takes a language attribute, its child elements
(family, given, other, prefix, suffix) no longer take the language
attribute. This is to force one language representation for each n
element, instead of one n element holding multiple language
representations.  This does deviate from RFC 2426, but I think it
makes the XML representation easier to implement and read.



I suggest this should be added to whole draft document and submitted
as either a new draft, to replace the existing document which will
expire soon, or possibly form part of a submission for a proposed
standard, or an informational  specification, to the IETF.

Martin Lee



   <?xml version="1.0" encoding="UTF-8"?>

   <!-- ******************************************** -->
   <!-- Entity declarations and references -->
   <!-- ******************************************** -->

   <!ENTITY % attr.lang "
        xml.lang NMTOKEN #IMPLIED
   ">
   <!-- lang value is a valid RFC 1766 language string -->

   <!ENTITY % attr.del "
        del.type NMTOKENS 'INTL POSTAL PARCEL WORK'
   ">
   <!-- Valid name tokens are "INTL", "DOM", "POSTAL", "PARCEL"
        "WORK", "HOME" -->

   <!ENTITY % attr.tel "
        tel.type NMTOKENS 'VOICE'
   ">
   <!-- Valid name tokens are "HOME", "WORK", "MSG", "PREF"
        "VOICE", "FAX", "CELL", "VIDEO", "PAGER", "BBS", "MODEM"
        "CAR", "ISDN", "PCS" -->

   <!ENTITY % attr.email "
        email.type NMTOKENS 'INTERNET'
   ">
   <!-- Valid name tokens are "INTERNET", "X.400", "PREF" -->

   <!ENTITY % attr.img "
        img.type CDATA #REQUIRED
   ">
   <!-- img.type value is an IANA registered image type -->

   <!ENTITY % attr.aud "
        aud.type CDATA #REQUIRED
   ">
   <!-- aud.type value is an IANA registered audio type -->

   <!-- The mandatory properties in any vCard -->
   <!ENTITY % prop.man "
        (fn, n)
   ">

   <!-- Identification properties -->
   <!ENTITY % prop.id "
        (nickname | photo | bday)
   ">

   <!-- Delivery addressing properties -->
   <!ENTITY % prop.del "
        (adr | label)
   ">

   <!-- Telecommunications addressing properties -->
   <!ENTITY % prop.tel "
        (tel | email | mailer)
   ">

   <!-- Geographical properties -->
   <!ENTITY % prop.geo "
        (tz | geo)
   ">

   <!-- Organizational properties -->
   <!ENTITY % prop.org "
        (title | role | logo | agent | org)
   ">

   <!-- Explanatory propeties -->
   <!ENTITY % prop.exp "
        (categories | note | sort | sound | url)
   ">

   <!-- Security properties -->
   <!ENTITY % prop.sec "
        (key)
   ">

   <!-- ******************************************** -->
   <!-- vCard value type notation declarations -->
   <!-- ******************************************** -->

   <!NOTATION URI PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   URI//EN">

   <!NOTATION TEXT PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Text//EN">

   <!NOTATION DATE PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Date//EN">

   <!NOTATION TIME PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Time//EN">

   <!NOTATION DATE-TIME PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Date-Time//EN">

   <!NOTATION INTEGER PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Integer//EN">

   <!NOTATION BOOLEAN PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Boolean//EN">

   <!NOTATION FLOAT PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Float//EN">

   <!NOTATION X-NAME PUBLIC "-//IETF//NOTATION VCARDXML/Value Type X-
   Name//EN">

   <!NOTATION BINARY PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   Binary//EN">

   <!NOTATION VCARD PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   vCard//EN">

   <!NOTATION PHONE-NUMBER PUBLIC "-//IETF//NOTATION VCARDXML/Value Type

   Phone-Number//EN">

   <!NOTATION UTC-OFFSET PUBLIC "-//IETF//NOTATION VCARDXML/Value Type
   UTC-Offset//EN">

   <!-- ******************************************** -->
   <!-- vCard element and attribute declarations -->
   <!-- ******************************************** -->

   <!ELEMENT vCardSet (vCard*)>
   <!ATTLIST vCardSet name CDATA #IMPLIED>

   <!ELEMENT vCard      (%prop.man;+, %prop.id;?, %prop.del;*,
%prop.tel;*,  %prop.geo;*,
        %prop.org;*, %prop.exp;?, %prop.sec;?)>

   <!ATTLIST vCard
        %attr.lang;
        xmlns CDATA #FIXED 'http://www.ietf.org/internet-drafts/draft-

   dawson-vcard-xml-dtd-03.txt'
        xmlns:vcf CDATA #FIXED 'http://www.ietf.org/internet-

   drafts/draft-dawson-vcard-xml-dtd-03.txt'
        version CDATA #REQUIRED
        rev CDATA #IMPLIED
        uid CDATA #IMPLIED
        prodid CDATA #IMPLIED
        class (PUBLIC | PRIVATE | CONFIDENTIAL) "PUBLIC"
        value NOTATION (VCARD) #IMPLIED>
   <!-- version - Must be "3.0" if document conforms to this spec -->
   <!-- rev - ISO 8601 formatted date or date/time string -->
   <!-- uid - UID associated with the object described by the vCard -->
   <!-- prodid - ISO 9070 FPI for product that generated vCard -->
   <!-- class - Security classification for vCard information -->

   <!-- Identification properties -->
   <!-- Element and attribute declarations -->
   <!ELEMENT fn (#PCDATA)>
   <!ATTLIST fn
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT n (family?, given?, other*, prefix*, suffix*)>
   <!ATTLIST n
        %attr.lang;>

   <!ELEMENT family (#PCDATA)>
   <!ATTLIST family
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT given (#PCDATA)>
   <!ATTLIST given
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT other (#PCDATA)>
   <!ATTLIST other
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT prefix (#PCDATA)>
   <!ATTLIST prefix
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT suffix (#PCDATA)>
   <!ATTLIST suffix
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT nickname (#PCDATA)>
   <!ATTLIST nickname
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT photo (extref | b64bin)>
   <!ATTLIST photo
        %attr.img;>

   <!-- extref holds a reference to an external entity that -->
   <!-- has the photo. b64bin holds the inline BASE64 encoded -->
   <!-- binary data for the photo as defined in RFC 2045. -->

   <!ELEMENT extref EMPTY>
   <!ATTLIST extref
        uri ENTITY #REQUIRED>

   <!ELEMENT b64bin (#PCDATA)>
   <!ATTLIST b64bin value NOTATION (BINARY) #IMPLIED>

   <!ELEMENT bday (#PCDATA)>
   <!ATTLIST bday value NOTATION (DATE | DATE-TIME) #IMPLIED>

   <!-- bday holds a ISO 8601 formatted date or date/time string -->
   <!-- value MUST be "DATE" for a date string and "DATE-TIME" for -->
   <!--   date/time string. -->

   <!-- Delivery addressing properties -->
   <!-- Element and attribute declarations -->

   <!ELEMENT adr (pobox?, extadd*, street?, locality*, region?,
                pcode?, country?)>
   <!ATTLIST adr
        %attr.del; >

   <!ELEMENT pobox (#PCDATA)>
   <!ATTLIST pobox
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT extadd (#PCDATA)>

   <!ATTLIST extadd
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT street (#PCDATA)>
   <!ATTLIST street
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT locality (#PCDATA)>
   <!ATTLIST locality
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT region (#PCDATA)>
   <!ATTLIST region
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT pcode (#PCDATA)>
   <!ATTLIST pcode
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT country (#PCDATA)>
   <!ATTLIST country
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT label (#PCDATA)*>
   <!ATTLIST label
        %attr.del;
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!-- Telecommunications addressing properties -->
   <!-- Element and attribute declarations -->

   <!ELEMENT tel (#PCDATA)>
   <!-- A valid ITU standard telephone numbers string. -->
   <!ATTLIST tel
        %attr.tel;
        value NOTATION (PHONE-NUMBER) #IMPLIED>

   <!ELEMENT email (#PCDATA)>
   <!ATTLIST email
        %attr.email;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT mailer (#PCDATA)>
   <!ATTLIST mailer
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!-- Geographical properties -->
   <!-- Element and attribute declarations -->

   <!ELEMENT tz (#PCDATA)>
   <!ATTLIST tz value NOTATION (UTC-OFFSET) #IMPLIED>
   <!-- tz holds an ISO 8601 formatted time zone offset. -->

   <!ELEMENT geo (lat, lon)>

   <!ELEMENT lat (#PCDATA)>
   <!ATTLIST lat value NOTATION (FLOAT) #IMPLIED>
   <!-- A decimal degree float number to 6 decimal places -->

   <!ELEMENT lon (#PCDATA)>
   <!ATTLIST lon value NOTATION (FLOAT) #IMPLIED>
   <!-- A decimal degree float number to 6 decimal places -->

   <!-- Organizational properties -->
   <!-- Element and attribute declarations -->

   <!ELEMENT title (#PCDATA)>
   <!ATTLIST title
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT role (#PCDATA)>
   <!ATTLIST role
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT logo (extref | b64bin)>
   <!ATTLIST logo
        %attr.img;>

   <!-- extref holds a reference to an external entity that -->
   <!-- has the logo. b64bin holds the inline BASE64 encoded -->
   <!-- binary data for the logo as defined in RFC 2045. -->

   <!ELEMENT agent (vCard | extref)>

   <!-- value MUST be "VCARD" for a "vCard" content model and -->
   <!--   "URI" for a "extref" content model. -->

   <!ELEMENT org (orgnam, orgunit*)>

   <!ELEMENT orgnam (#PCDATA)>
   <!ATTLIST orgnam
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>
   <!ELEMENT orgunit (#PCDATA)>
   <!ATTLIST orgunit
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!-- Explanatory properties -->
   <!-- Element and attribute declarations -->

   <!ELEMENT categories (item)*>

   <!ELEMENT item (#PCDATA)>
   <!ATTLIST item
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT note (#PCDATA)*>
   <!ATTLIST note
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT sort (#PCDATA)>
   <!ATTLIST sort
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT sound (extref | b64bin)>
   <!ATTLIST sound
        %attr.aud;>

   <!-- extref holds a reference to an external entity that -->
   <!-- has the sound. b64bin holds the inline BASE64 encoded -->
   <!-- binary data for the sound as defined in RFC 2045. -->

   <!ELEMENT url EMPTY>
   <!ATTLIST url
        uri ENTITY #REQUIRED>
   <!-- url holds a RFC 1738 formatted Uniform Resource Locator -->

   <!-- Security properties -->
   <!-- Element and attribute declarations -->

   <!ELEMENT key (extref | b64bin)>

   <!-- extref holds a reference to an external entity that -->
   <!--   has the key or cert. base64-data has the actual data for -->
   <!--   the key or cert, encoded with Base64 as defined in the -->
   <!--   MIME spec. -->

Re: vCard XML DTD comments 02

I wanted to reply to the comments of Randal Leavitt that havent been
already addressed.


1) "... However, if we want to have a vCard in Chinese what do we do?
Tokens such
as "VOICE" and "MSG" will not be vary understandable in China. I think
we need a
separate DTD for each language. ..."
This is an implementation issue. The DTD is not visible to the end user,
neither should the
raw data be, it needs to be interpreted by a parser and presented in an
appropriate way
to the user. Only the developer needs to understand the DTD, if they
need an entire
translation of the specification then they need to have it translated.
Appropriate language attributes for tags and use of unicode mark-up
should make a
vCard-XML document presentable in any language.


2 ) "In Section 2 the attribute "lang" is defined. I think it would be
better to declare this
attribute as "xml:lang" to more closely follow the XML standard."
I agree. The two attributes are identical. "lang value is a valid RFC
1766 language string",
from the  DTD. "The values of the attribute [xml:lang]  are language
identifiers as defined
by IETF RFC 1766" from http://www.w3.org/TR/1998/REC-xml-19980210 , the
XML
1.0 specification. I would suggest as it is an XML definition we should
use XML properties
where possible and not define our own syntax where identical
functionality is already
provided by XML itself. Therefore use the predefined xml:lang attribute
in place of an
identical but self defined lang attribute.


4) "The "lang" attribute is specified for many of the vCard elements.
This is not pragmatic.
It should only be an attribute of the vCard element itself, and should
apply to the whole
card. "
I disagree the vCard refers to an instance of a person who may be known
by different
names or have different expresions of their properties in different
languages. If I receive
one vCard with a choice of language representations for that person,
then I may choose
the representation I prefer to suit my prefered language. If I receive
two different vCards
one in English, one in French for example I have no way of knowing if
this relates to two
individuals one a French man, one an English man who have similar
properties or to two
representations of one individual.

5) "In the entity "prop.tel" I would include another child element
called "web" or "net"
and remove the "url" element in "prop.exp"."
This would break the DTD's representation of RFC 2426 (the goal of the
group). In any
case the structure of an XML document does not represent the
'importance' of any piece
of information just how it is ordered.

7) "The element "n" forces me to give my family name first.".
Only in the data, an implementation may choose to prompt you for a
family name later,
equally it could display names in any order.

8) "The element "n" will be valid if both the family name and given name
are omitted."
I agree, <!ELEMENT n (family*,given*,other*,prefix*,suffix*)> isnt
right. I think
<!ELEMENT n(family?,given?,other*,prefix*,suffix*)> is better, but I
this doesnt
solve the problem of omitting family and given names. But then again RFC
2426 has
the same problem.
If I'm being formal I might just want to give my name as Mr. Lee, to a
friend
I might be just 'Martin'. I see no way of solving this without forcing
someone to give
one name or the other, which I dont want to do. Ideas?


Martin

categories without items

The element categories is defined as:
<!ELEMENT categories (item)* >

This implies we can have a categories element in the absence of any
items,
i.e. just an empty tag, <categories></categories>.

I can see no reason for explicitly allowing empty elements. Defining
categories as:
<!ELEMENT categories (item)+ >
forces categories, if present, to have at least one item of information.

Martin