Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces

From: Andrew Newton <[email-masked]>
Date: Mon, 7 May 2007 14:43:35 -0400

On Apr 27, 2007, at 10:35 PM, Henning Schulzrinne wrote:

> This concrete example is helpful.
>
> Since applications such as LoST don't typically do schema  
> validation, maybe it's more helpful to look at what an application  
> would actually do, such as using SAX and DOM.
>
> Clearly, the application only has a limited repertoire of XML tags  
> that it recognizes and then parses. It will presumably build up its  
> internal data structure from those elements.
>
> There are two cases:
>
> (1) Senders can only generate certain orderings of elements, such  
> as Point followed by civicAddress, even though the schema allows  
> any ordering. A 'profile' specifies this.
>
> (2) Any ordering permitted by the schema can appear in the XML  
> document.
>
> Doing (1) simplifies processing, since there are fewer elements  
> that can occur at any given time, but with an event-based or DOM- 
> based model, it doesn't seem to make a whole lot of difference.

There was a leap in logic to "doesn't seem to make a whole lot of  
difference" that I don't understand.  As far as ingesting the data in  
to data structures, yes.  As far as recognition of the semantics, the  
server is still left to attempting to figure out what profile the  
sender is using without any hints.

Given your logic, you could argue that XML namespace declarations are  
completed unneeded as applications should be able to know that when  
tag <foo> always precedes tag <bar>, they are dealing with tags from  
the http://example.com/foobar namespace.

> We obviously do want to restrict the GML elements that can occur in  
> the XML sent, but that's a standardization issue, not a labeling  
> issue. Thus, I'm all in favor of defining profiles for the sender.

We are in agreement here.

> I just don't see how a profile label (beyond the namespace  
> indications) would simplify the processing or improve error  
> processing.

Because, it would allow the sender to tell the server which profile  
it was sending.  Since neither of us seem to be advocating XML  
validation in this case, I be happy to compromise and say that  
senders do not have to include the profile identifier if they don't  
know it.  Is that workable?

-andy

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 7 May 2007 23:08:43 -0400

> difference" that I don't understand.  As far as ingesting the data  
> in to data structures, yes.  As far as recognition of the  
> semantics, the server is still left to attempting to figure out  
> what profile the sender is using without any hints.

I don't see what hints you can offer in this particular case. As far  
as I know, we have not attributed any semantics to the ordering of  
the elements. In general, I think it would be a bad idea to do so,  
given that the schema considers both orderings equivalent.

>
> Given your logic, you could argue that XML namespace declarations  
> are completed unneeded as applications should be able to know that  
> when tag <foo> always precedes tag <bar>, they are dealing with  
> tags from the http://example.com/foobar namespace.

I'm making no such leap. The namespace defines what elements are  
legal and is required for validation. (I'm guessing I agree with you  
that most XML parsers ignore the namespace declaration, but that  
doesn't mean that they are unnecessary. After all, we want to *allow*  
validation at the receiver, even if we don't require it and even if  
most systems won't perform it except maybe in debug mode.)

> know it.  Is that workable?

That's certainly a step in the right direction and probably the  
minimum we need to do.

However, including the label simply adds another error condition that  
needs to be tested for. Now, the recipient has to verify whether  
profile and content agree. The most likely consequence is that most  
receivers will simply ignore the profile label. Such 'latent' error  
conditions are not good, as a mislabeling sender will likely not get  
an error message except from some small subset of hyper-sensitive  
implementations - which may then only occur during an emergency, when  
it's too late to fix.

Or are you suggesting that the receiver treat this only as a hint and  
ignore the label if it contradicts the XML?

(We have a version of this problem today. IE and maybe other browsers  
will ignore the Content-Type header and render based on inspecting  
the content, since many webservers get the Content-Type wrong. I'm  
not advocating this as good programming practice, but it shows the  
likely outcome.)

---

From: Andrew Newton <[email-masked]>
Date: Wed, 9 May 2007 09:33:10 -0400

On May 7, 2007, at 11:08 PM, Henning Schulzrinne wrote:
> I don't see what hints you can offer in this particular case. As  
> far as I know, we have not attributed any semantics to the ordering  
> of the elements. In general, I think it would be a bad idea to do  
> so, given that the schema considers both orderings equivalent.

Consider location profiles that are not yet defined.  Which one is this?

<gml:Point srsName="urn:ogc:def:crs:EPSG::4979">
   <gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
   <gml:pos>
     -34.409 150.879
   </gml:pos>
   <gml:radius uom="urn:ogc:def:uom:EPSG::9001">
     850.24
   </gml:radius>
</gs:Circle>

Of course, if you are suggesting that future profiles the glue  
multiple elements together such as this would need to define their  
own schema to properly define them, then I consider that a fair  
design choice.  That does mean that the current method of 3825  
compound location defined in pdif-lo-profile would need a schema that  
wraps the gml and civicAddress.

Also, why would the LoST server need to identify profiles then?  It  
should use the same XML namespace mechanism.

>> Because, it would allow the sender to tell the server which  
>> profile it was sending.  Since neither of us seem to be advocating  
>> XML validation in this case, I be happy to compromise and say that  
>> senders do not have to include the profile identifier if they  
>> don't know it.  Is that workable?
>
> However, including the label simply adds another error condition  
> that needs to be tested for. Now, the recipient has to verify  
> whether profile and content agree. The most likely consequence is  
> that most receivers will simply ignore the profile label. Such  
> 'latent' error conditions are not good, as a mislabeling sender  
> will likely not get an error message except from some small subset  
> of hyper-sensitive implementations - which may then only occur  
> during an emergency, when it's too late to fix.

There is no need to add another error condition.  Either the server  
knows what it is looking at or it doesn't.

> Or are you suggesting that the receiver treat this only as a hint  
> and ignore the label if it contradicts the XML?

Yes.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 11:03:22 -0400

On May 9, 2007, at 9:33 AM, Andrew Newton wrote:

>> far as I know, we have not attributed any semantics to the  
>> ordering of the elements. In general, I think it would be a bad  
>> idea to do so, given that the schema considers both orderings  
>> equivalent.
>

Obviously, there's no way to tell. But I thought we earlier agreed  
that unknown GML would get no profile label. The important part is  
that the receiver can recognize the GML. If it doesn't recognize the  
combination of point and circle, it is going to have to throw in the  
towel, with or without a profile label.

> compound location defined in pdif-lo-profile would need a schema  
> that wraps the gml and civicAddress.
>

No, it should recognize it by the the combinations of elements that  
it supports. If it sees something it can't recognize, it has to  
return an error.

The only question is whether it should ignore elements that it  
doesn't understand, as in

<Point>...</Point>
<Blob>..</Blob>

Should it ignore the blob and just go with the point?

The compound locations in draft-ietf-geopriv-pdif-lo-profile-07 have  
well-defined rules as to what should come first and what can be  
included, so I fail to see the problem. (Again, we do need to  
coordinate that whatever is legal in LIS, according to the phone-bcp  
or whatever other document, is also legal in LoST, to avoid problems.  
That, however, isn't fixed or affected by a profile indication.)

>> and ignore the label if it contradicts the XML?

As long as we specify this as a 'MAY insert as a hint' and 'receiver  
MUST ignore if it contradicts the XML', I'm not too hung up about  
including it. The use seems limited, but harmless.