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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

> > (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.

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.)


> > 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?

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.)

> -andy


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit