[Dev] Parcel namespaces and the schema API

[Phillip J. Eby]

At 10:52 AM 5/11/2005 -0700, Lisa Dusseault wrote:
>Not that there's any rush on this anyway and probably not a 0.6 priority 
>-- I was just responding to some design implications.
>
>But, is it possible that we don't need new namespaces anyway?  It's 
>possible to define our XML schema used in parcel definition, such that any 
>element or attribute used in parcel definition files would come from our 
>definition format, thus these could all appear in a single 
>namespace.  Then, we could set it up such that 3rd party parcels never 
>defined new element or attribute names, just new data.
>
>However, note that this is definitely a rehashing of old arguments (and a 
>sign of my obsession over things like namespace).  Morgen & I looked at 
>this a year ago and tried to remove the need for a 3rd party parcel to 
>define any new XML element or attribute names.  It got a little awkward to 
>clean this up -- the "hack" I perceived made the syntax simpler once you 
>grokked the hack.  It's related to another "hack" which is to use 
>namespace prefixes inside attribute values -- another XML namespace usage 
>no-no.  Now that we're making parcel definition changes, it may be much 
>easier to avoid using namespaces and prefixes at all when referring to 
>stuff inside another parcel.

Possibly so; I think this will be easier to see once the existing 
parcel.xml files lose their schema parts.  I also think it's quite likely 
that, except for UI items, it may become simpler for people to define any 
parcel-supplied items in their Python code.  The import mechanism Andi 
created to support schema definition is not restricted to schema items 
only, and so far I've found it quite easy to use.

If that turns out to be the case, then it opens the door to having an XML 
dialect optimized for creating Chandler UI items that would be easier to 
learn than generic parcel.xml format.  And, for simple one-offs like 
WakeupCaller and the like, it's possible now for a user to create them like 
this in the body of a module using the Schema API:

     WakeupCaller(
         parent=schema.parcel_for_module(__name__), name="ProcessZaoBaoFeeds",
         wakeupCallClass="osaf.examples.zaobao.ZaoBaoWakeupCall.WakeupCall",
         callOnStartup=True, enabled=True, repeat=True, delay="00:00:30:00"
     )

Which is somewhat more compact than the parcel.xml version.  This object 
then automatically gets added to the module's parcel under the path 
//parcels/osaf/examples/zaobao/ProcessZaoBaoFeeds.

So, as far as I can see, the main remaining use of parcel.xml is probably 
going to be for defining the UI, and we could probably create a more 
user-friendly XML dialect for that.

When in some future version of Chandler, non-programmers can define schema 
and items as a parcel, the interchange format can be the repository's 
"native XML" format, which isn't an especially user-friendly format, but it 
doesn't have to be because you'll never write it by hand anyway.  (Except 
for its core schema, of course.)