Subject: [Geopriv] Geolocation Policy Draft & <description> element

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 02 Oct 2007 15:53:13 +0200

Hi all,

Henning and I investigated how to add a <description> element to Common 
Policy in order to provide a human readable description of the rule (as 
suggested by Lisa).

It looked like a reasonable idea and here is an example how it could 
look like:

<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
       <rule id="f3g44r1">
           <conditions>
               <identity>
                   <one id="sip:[email-masked]"/>
               </identity>
               <sphere value="work"/>
               <validity>
                   <from>2003-12-24T17:00:00+01:00</from>
                   <until>2003-12-24T19:00:00+01:00</until>
               </validity>
           </conditions>
           <actions/>
           <transformations/>
           <description lang="en">
           This is the basic rule I use while I am at work.
           </description>
       </rule>
   </ruleset>

Unfortunately, we recognized a problem with the "simple" extension. We 
did not provide extension points for the <rule> and the <ruleset> element.
In short, we cannot extend the schema in a simple fashion without 
introducing backwards compatibility issues. At this level we believe 
that we only have one way of extending the document, namely by revising 
Common Policy and by registering a new URI (such as URI: 
urn:ietf:params:xml:ns:common-policy2).

Proposal: We would add the <description> element when we revise the 
document. Thereby, we could reflect what other SDOs did with the 
document and eventually provide other bug fixes and implementation 
considerations as well.

Thoughts?

Ciao
Hannes

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

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 3 Oct 2007 15:46:34 -0700

Does this mean that generally as used by Geopriv, that the Extensible  
Markup Language is *not* extensible?  Yikes.  There should be  
language about where extension elements *may not* appear, and clients  
should elsewhere be able to handle extension elements by just  
ignoring them.

If that's not the case, I've seriously misunderstood your message.

Thanks,
Lisa

On Oct 2, 2007, at 6:53 AM, Hannes Tschofenig wrote:

> Hi all,
>
> Henning and I investigated how to add a <description> element to  
> Common Policy in order to provide a human readable description of  
> the rule (as suggested by Lisa).
>
> It looked like a reasonable idea and here is an example how it  
> could look like:
>
> Unfortunately, we recognized a problem with the "simple" extension.  
> We did not provide extension points for the <rule> and the  
> <ruleset> element.
> introducing backwards compatibility issues. At this level we  
> believe that we only have one way of extending the document, namely  
> by revising Common Policy and by registering a new URI (such as  
> URI: urn:ietf:params:xml:ns:common-policy2).
>

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 05 Oct 2007 16:28:50 +0300

ext Lisa Dusseault wrote:
> Markup Language is *not* extensible?  Yikes.  There should be language 
> about where extension elements *may not* appear, and clients should 
> elsewhere be able to handle extension elements by just ignoring them.
>
I've ranted about xml extensions too many times, so sorry to continue... 
In many cases we have adopted a model where the first submitted schema 
_must_ be the most liberal one, then the following extension schemas 
just basically limit the baseline schema. All of this is done so that we 
accomplish forwards and backwards compatibility. So when defining the 
baseline schema a lot of carefulness is needed if there's a requirement 
to fulfill this. Unfortunately, quite many schemas have been done with 
the w3c schema 1.0 tool, which doesn't allow flexible extensions unlike 
relax ng which seems to be gaining popularity in ietf finally. However, 
even using relax doesn't change the fact that the baseline must be 
liberal. Of course, one can always argue, whether valid xml according to 
these schemas is always needed, as an implementor i happen to like them 
because you can typically find some bugs or avoid some interoperability 
problems by using them (at least when the xml-content _is_ complex).

But as discussed with Hannes, this particular case is such that the 
baseline happens to be too restricting, unfortunately. So no easy way out...
br, jari