[Dev] Parcel namespaces and the schema API

[John Anderson]

I'm a little behind on reading this entire thread -- and maybe don't 
understand the proposal very well -- however, we need a way for parcels 
to contain only data (no code) and refer to data in other parcels, so if 
we don't use name spaces to refer to other parcels, does that mean we 
use Python modules? Most of the parcels that exist today (and I suspect 
in the future) are data only and don't belong to a Python module. They 
are  just a bunch of items organized in the repository using the native 
repostitory data structures.

I suspect the majority of items happen to be UI, but that's only because 
most of the kinds of data are used for UI. There isn't anything special 
about UI items, in fact all the items that are Chandler expects to be in 
a "new" repository will  typically be populated in the repository the 
same way, e.g. ItemCollections, templates for ContentItems, and various 
housekeeping data structures for finding things easily. So I think it's 
a mistake to come up with two ways to populate items in the repository, 
one for UI and one for non-UI. I think we couldn't come up with a 
single, simple to use, format that works for both.

John

John

Phillip J. Eby wrote:

> 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.)
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev