Subject: Re: [Ecrit] Additional Data 24 Comments

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jul 2015 11:51:25 -0700

-- My apologies, I just noticed this message from 
last year, and am not sure if it was ever sent or 
not.
-- Randall Gellens

At 6:01 PM +0000 11/7/14, Chris Santer wrote:

>  After reviewing version 24, our team came up with some new comments:

Thanks, I appreciate it.

>
>  ·         The draft should probably make 
> 'provided-by' all lower case; in 5.3 it is 
> 'Provided-By'.  Xml tags are case sensitive, 
> and RFC 4119 shows it in all lower case when 
> quoting in text (see section 2.2.4).

Fixed in -25.

>  ·         The example in draft 24 section 5.3 
> now shows the 'EmergencyCallDataValue' element 
> in the geopriv10 namespace, which seems 
> incorrect.

Fixed in -25.

>  ·         There is a 'DataProviderReference' 
> element defined in the 
> EmergencyCallData:ProviderInfo namespace - 
> however it doesn't actually fall within the 
> ProviderInfoType definition like it does in 
> other info types, and like it is used in the 
> examples.  This does seem like a problem in the 
> schema.

Fixed in -25.

>  ·         Also not sure if the 
> 'DataProviderReference' element that is shown 
> directly in the PIDF-LO 'provided-by' is really 
> supposed to be there.

No, it isn't.  Thanks.  Fixed in -25.

>  ·         The DataProviderContact element is 
> declared in the schema as an "xc:vcardType"; 
> instead, it should be declared as a type within 
> the EmergencyCallData:ProviderInfo namespace 
> that contains a 'vcards' element from the 
> vcard-4.0 namespace.  Specifically note the use 
> of 'vcards' plural.  This is because RFC 6351 
> explicitly states The <vcards> element MUST be 
> present even when only a single vCard is 
> present in an XML document.  The schema in 24 
> points to the single vCard definition, and most 
> (but not all) of the examples also show a 
> single vCard, and this appears to be a 
> violation of the RFC.
>  ·         The SubscriberData element in 
> EmergencyCallData:SubscriberInfo has the same 
> problem as DataProviderContact above.
>  ·         The schema shows an 'id' element as 
> mandatory, but not all examples show this 
> element and I don't see any explanation what 
> it's for.  Section 4.1.2 states that a 
> 'ProviderID' element is required, but the 
> schema has minOccurs="0".  Several other 
> elements are in the same boat.

I believe these have all been fixed in -25.  If 
you could double-check that no such problems 
remain, I'd be grateful.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Television is simply automated day-dreaming.
       --Lee Lovinger, _Quote_, July 30, 1967

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 07 Jul 2015 22:29:28 +0200

Hi Randy, Hi Chris,

On 07/07/2015 08:51 PM, Randall Gellens wrote:
> 
>>  ·         The DataProviderContact element is declared in the schema
>> as an "xc:vcardType"; instead, it should be declared as a type within
>> the EmergencyCallData:ProviderInfo namespace that contains a 'vcards'
>> element from the vcard-4.0 namespace.  Specifically note the use of
>> 'vcards' plural.  This is because RFC 6351 explicitly states The
>> <vcards> element MUST be present even when only a single vCard is
>> present in an XML document.  The schema in 24 points to the single
>> vCard definition, and most (but not all) of the examples also show a
>> single vCard, and this appears to be a violation of the RFC.
>> EmergencyCallData:SubscriberInfo has the same problem as
>> DataProviderContact above.

Your observation is correct, Chris. We are indeed only re-using part of
RFC 6351.

RFC 6351 indeed says:

"
   A top-level <vcards> element is used as root.  It contains one or
   more <vcard> elements, each representing a complete vCard.  The
   <vcards> element MUST be present even when only a single vCard is
   present in an XML document.
"

We did, however, got rid of the <vcards> element and instead place one
or more <vcard> elements directly as child elements of <SubscriberData>
and <DataProviderContact>.

The question for me is whether it matters. Do we want to have an
additional <vcards> element in our instance documents? The problem is
that it does not really serve any purpose in our context. In the vcard
space it is a bit different since you need to have a top-level element,
which is this <vcards> element but in our case we place the <vcard>
elements in other elements.

I am happy to make change the schema and the examples if you guys think
it is a good idea. If we don't make that change we need to be explicit
about the difference to RFC 6351.

>>  ·         The schema shows an 'id' element as mandatory, but not all
>> examples show this element and I don't see any explanation what it's
>> for.  
In the latest version we don't seem to have that element in there anymore.

>> Section 4.1.2 states that a 'ProviderID' element is required,
>> but the schema has minOccurs="0".  Several other elements are in the
>> same boat. 

This is fixed with the latest version but it turns out to be really
difficult to keep things in sync between the textual description, the
XML schemas, and the examples. Thanks for reading through the document
so carefully!

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 08 Jul 2015 07:53:09 +0200

I agree with you, Archie.

I think the current solution is good and, as you said, we are using the
<vcard> differently than RFC 6351 does as a standalone.

On 07/08/2015 12:28 AM, archie cobbs wrote:
> We've already flip-flopped between <vcard> and <vcards> twice, please
> let's not change it again.
> 
> It seems clear to me that what that quoted sentence means is that you
> should not send an XML document with <vcard> as the document root
> element. This is entirely reasonable, and does not impact usage when
> embedding the <vcard> inside a larger XML document as we are doing.
> 
> -Archie

---

From: archie cobbs <[email-masked]>
Date: Tue, 7 Jul 2015 17:28:20 -0500

On Tue, Jul 7, 2015 at 3:29 PM, Hannes Tschofenig <[email-masked]
> wrote:

>    present in an XML document.

We've already flip-flopped between <vcard> and <vcards> twice, please let's
not change it again.

It seems clear to me that what that quoted sentence means is that you
should not send an XML document with <vcard> as the document root element.
This is entirely reasonable, and does not impact usage when embedding the
<vcard> inside a larger XML document as we are doing.

-Archie

-- 

Archie Cobbs

Distinguished Member of Technical Staff
Emergency CallWorks

<http://emergencycallworks.com>http://emergencycallworks.com/
O: +205-979-1412

M: +205-907-3599
E:  <http://@emergencycallworks.com>[email-masked]
<[email-masked]>*