EditAttachWiki Help
r68 - 08 Mar 2006 - 10:51:30 - AlecFlettYou are here: OSAF >  Projects Web  >  ChandlerHome > ObsoleteChandlerInformation > ParcelFramework

Parcel Project

The parcel loading framework creates items in the repository, based on data read in from XML files.

Active Contributors

Project Status

0.5 goals TBD

Documentation

See ParcelManager for an overview.

See ParcelFrameworkChanges for the log of parcel loader changes.

0.5 Planning

To Do:

Feature Estimate Status Milestone
Warn about data/schema in same file      
Propose and implement streamlined cloud definition syntax      
Support import of Text and Binary LOB values      

Completed:

Feature Estimate Status Milestone
Generate schema documentation 3 days Done  
Switch copy function to use Clouds   Done  
Parcel reloading 3 days Done 0.3.20 (7/13)
Automatically set superKind if not assigned .5 days Done 0.3.20 (7/13)
Automatically link up local attributes 1 day Done 0.3.20 (7/13)

Open issues

  • Having schema (kinds and attributes) and data items defined in the same file makes it tricky/inefficient to load in items because we can't create data items in the repository until all schema items have been fully loaded
Usually, the way the parcel loader handles this works fine -- the corner case where it breaks down is when parcel A defines Kind K1 and date item I, parcel B defines Kind K2 which is K1's superKind and K2 has a custom class. Item I's init method won't get called because the custom class hasn't been hooked up to K2 before I is created. TODO: Issue a warning if data and schema are in the same file, or perhaps try to detect this corner case and prevent/handle it.

  • When assigning attributes in XML, are the attribute elements specified with namespace-qualified names or are they just strings matching the kind's attribute names?
For example: 
1: <core:Kind itemName="foo">
2:    <attributes itemref="ns:attr"/>
3: <core:Kind/>
That XML snippet defines a item named "foo" of kind //Schema/Core/Kind, and assigns a value to its "attributes" attribute. In the current implementation, when an XML element represents an attribute assigment as in line 2 above (as opposed to an item definition element as in line 1), the namespace of that element is ignored; the element's name is passed directly to the appropriate kind's getAttribute( ) method to determine which attribute to use to makeValue( ). This makes some sense given what we're trying to do, but it's a bit inconsistent. The proposal? I don't have an alternative to this that I like, and might suggest leaving it the way it is. We could try to make this more XML-correct by using an <assignment> element for each attribute assignment, and specify the attribute via name=" ", but it adds wordiness: 
<core:Kind itemName="foo">
    <core:assignment name="attributes" itemref="ns:attr"/>
<core:Kind/>

  • Think through the feature of "adding", "removing", "changing" items from the parcel xml.
The proposal is to check last-modified-times of parcel.xml files against times in the repo; if the on-disk copy is newer then build a list of that parcel's child items in the repository, and compare them against items in the XML -- remove the repo items that are not in the XML, and create the new items. For each item, wipe out all its attribute values (Andi says there is an API for this), and set all of them again based on the XML file. Note that one important issue this raises is all items that a parcel creates (not loaded from XML) need to be kept in a repository path that is outside of the parcel (in //userdata, or whatever). That way parcels can be re-loaded without affecting those items.

  • Support deleting of parcels (Bug:673)
What happens to items which are based on kinds defined in a deleted parcel, and also based on Python classes that are now missing?

  • The "default" aspect should not need a type assigned to it; it should just use the type of the attribute. (LOW)

  • Support structs/types. Requires a proposal for how to do this. (LOW, NEEDS DATA MODEL REQUIREMENTS)

  • Generate schema docs (MED-TO-LOW)

  • Add platform-specific tags to items (Bug:1032)

  • Add support for importing Text and Binary Lob values (MED)

  • Setting an attribute to refer to a query item, but dereferencing the attribute fetches the result of the query instead of the query item itself (ASK)

  • Add the equivalent of class attributes; be able to set a custom property on a Kind itself (use case: For each content item to be displayed in a table, its "whoAttribute" is looked at to see what other attribute really contains the data you want to display) (LOW)

  • Support versioning of parcels (LOW)

  • Parcels should have a manifest with checksums; a description of what files are contained and how to process them (LOW)

  • Add the ability to "extend" an item in another parcel with attributes defined in a new parcel. (Bug:1073) (LOW)

  • When loading parcels, overwriting a cardinality-single attribute that already has a assigned value, should generate a warning. (MED)

Closed Issues

(Also see ApplicationDataModelOpenIssues for Katie's description of some of these issues)

  • How does a parcel's filesystem location relate to where it lives in the repository?
In the current implementation, the relative path of a parcel.xml file is used to determine an item's repository path. For example, if Chandler/parcels/example/parcel.xml defines an item named "Foo", that item's repository path would be //parcels/example/Foo. If you want to define items in a different structure than how the parcel files are arranged in the filesystem, you can nest the item definitions in the XML -- element containment can be used to specify parent-child relationships in the repository. If the example Foo item's XML had a Bar item defined within it, Bar would be stored at //parcels/example/Foo/Bar. The proposal is to keep this simple mapping mechanism in place. (Also, think more about how the Python loader comes into play: packages and modules are usually loaded from the filesystem in directories mirroring their structure. Also look into Python zip loader)

  • We're overloading XML namespaces
The new parcel loader allows each parcel to explicitly register a namespace. If no namespace is registered, the parcel will be assigned one based on its parent parcel. When referring to parcels from now on, it should be via a namespace rather than repository path.

  • We don't have any parcel encapsulation
In the code you will sometimes see people referring to items inside other parcels. If the other parcel gets reorganized that can break your code. Now you can find another parcel by using the parcel manager's lookup method, passing in a namespace URI and getting back the parcel item that registered that URI; if an optional second string argument is passed in, that string is looked up within the namespace and the item it refers to is returned.

  • We want to support CPIA items in a first class manner
To define UI, parcels create items based on CPIA kinds. There is now a CPIA namespace "http://osafoundation.org/parcels/osaf/framework/blocks" (stored in the variable, application.parcel.CPIA) which defines all the CPIA XML element names.

  • Easier debugging for developers. Might include improvements to logging, asserts, etc. Might include schema validation.
Error reporting has definitely been improved. We could probably do something clever like create a DTD on-the-fly based on the schema items a developer defines, and then validate the data.xml. The proposal is for the parcel manager to validate XML against the schema namespaces that have been registered. If desired, we can also write a validation tool that runs outside of Chandler.

  • Resolve issues around empty list, none values, defaultValue, initialValue (Bug:1012)
You may now assign a collection attribute a defaultValue or initialValue of an empty collection by simply including "<defaultValue />" or "<initialValue/>" in that attribute's definition. An itemref attribute can be assigned to None by assigning it a special initialValue of //Schema/Core/None via "<initialValue itemref="core:None"/>"

  • Attribute items defined as children of Kinds does not imply the Kind has those attributes, they must also be linked up with the "attributes" tag. Is this a problematic redundancy? Should the parcel XML simplify this or reflect the structure of the repository?
"Local" attributes -- those which are a child of a Kind -- still do need to be added to that Kind's "attributes" attribute, but without using an alias. The proposal is to modify the parcel loader to scan for local attributes and make this assignment.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r68 < r67 < r66 < r65 < r64 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.