Subject: RE: [Simple] RPID: what does tuple-type really mean?

From: [email-masked]
Date: Wed, 23 Jun 2004 18:36:52 +0300

> >>I think it makes sense to use the same id attribute and space. My 
> >>question is, if you did this, would a client that implemented the 
> >>partial notification spec, but didnt know about a new <device> 
> >>element, peer to <tuple>, properly construct a PIDF 
> document when sent 
> >>partial notifications that indicate changes or removal of <device> 
> >>elements?
> > 
> > 
> > Well, that might work but in order to be on a safe side it would be 
> > better if clients would explicitly know about <device> elements. If 
> > attributes would have namespace this should not be a problem but as 
> > there is no way to know if id attribute really is the same id 
> > attribute there might be some nasty conflicts.
> 
> Sorry, I don't quite follow here. What does attribute 
> namespaces have to 
> do with it?

Ok, let's try to sort this out. As far as I know attributes in XML don't
belong to any namespace. This means that if we want to have id attribute
in <device> we need to separately define it within <device>. This id
also has (in XML) nothing to do with <tuple> id.
Now, if somebody would define a new element <foo> which would also have
id  attribute (with different semantics) client would have no way to
distinguish this from <tuple> id or from <device> id. This more or less
means that client must be explicitly aware of <device> element.

- Mikko

> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jun 2004 05:42:30 -0400

inline.

> means that client must be explicitly aware of <device> element.

I don't think that has to be the case. If you got an update that 
indicated that the document changed through the deletion of an element 
with id 3, the client could go through its current version of the 
document, select all elements under <presence> that have an "id" 
attribute with value 3, and delete them. This would work no matter what 
the name of those elements are.

Similarly, when an element shows up in a partial document, the client 
finds the matching one in its current document by matching the element 
name and id value, and updates it. This could also work without the 
client needing to understand the semantics of device.

For this to work though, I think the partial notification documents need 
to be clear that the algorithms apply to any child elements of 
<presence>, even ones not understood by the client, so long as they all 
have an "id" element.

-Jonathan R.

---

From: [email-masked]
Date: Thu, 24 Jun 2004 08:52:10 -0400 (EDT)

Before adding complexity, I still don't see why <device> provides any real
value. Can we agree on the requirements and objectives first, before
designing mechanisms?