Instead of overloading XML namespaces to indicate repository paths and parcel dependencies, move to a single namespace such as "http://osafoundation.org/schema/parcel/1.0/" to use for all the tags in a parcel file.

<Parcel xmlns="http://osafoundation.org/schema/parcel/1.0/" > 

Next we need the repository name and path for this parcel item; since we are shipping python code inside the parcels, and importing python requires that packages and modules have corresponding directories and files, we might as well have the repository path of parcel items be related to where the XML files live in the filesystem. So the repo path of a parcel in Chandler/parcels/OSAF/example/parcel.xml will still be //parcels/OSAF/example. We can just leave the name out of the XML, and the item name will be inferred from the directory name. On the other hand, the document generator seems to need the "describes" attribute in there so we have some redundancy. Ok, Jeffrey approved the removal of the "describes" attribute.

The describes attribute is used to construct relative paths from the not-quite absolute paths we've been using for references. We could supply the filesystem location of [...]Chandler/parcels to the XSLT engine as a command line option and we'd be able to remove the redundancy AND some ugly XSLT code, at the cost of adding a negligible bit of complexity to the generation process and a losing a little bit of XSL purity. We've already lost that purity by using EXSLT, though, so I think we should go ahead and do this. -- JeffreyHarris - 07 Apr 2004

For indicating dependencies and mnemonics for other parcels, a series of "import" statements (or "uses", "dependsOn", etc.) could be used. Dereferencing a mnemonic is done by prefixing it with "@"; in the example below, "@cm" would resolve to the parcel item //parcels/OSAF/contentmodel. You can refer to items contained in a parcel by appending a repository path like "@cm/contacts/Contact". Wherever an item reference is being made, you can use the "@" syntax, or you can use a repository path syntax relative to the "current item". For example, the <attributes> element is used to assign an attribute to a kind and the content of that element is a string which needs to be converted into an item reference; the string "date" in this example would resolve to the date item which is a peer of CalendarEvent^? (although I might want to make it "../date" to be consistent with the repository, I don't know yet). Using ".." would refer to the parent item. Or "@this/date" (where "@this" is a prefix that's automatically defined to mean the current parcel) would also refer to the date item.

    <import parcel="OSAF/core" version="0.3" prefix="core" />
    <import parcel="OSAF/example" version="0.3" prefix="ex" />
    <import parcel="OSAF/contentmodel" version="0.3" prefix="cm" />
    <import parcel="OSAF/framework/agents" version="0.3" prefix="ag" />

    <Schema>

        <Kind itsName="CalendarEvent">
            <superKinds>@cm/ContentItem</superKinds>

            <-- adding attributes only necessary if they're not local -->

            <attributes>date</attributes>
            <attributes alias="aka">@cm/related</attributes>

            <Attribute itsName="linksTo">
                <type>..</type>  (or <type>@this/CalendarEvent</type>)
                <cardinality>List</cardinality>
                <required>False</required>
                <inverse>linkedFrom</inverse>
                </Attribute>

            <Attribute itsName="linkedFrom">
                <type>..</type>  (or <type>@this/CalendarEvent</type>)
                <cardinality>List</cardinality>
                <required>False</required>
                <inverse>linksTo</inverse>
            </Attribute>

        </Kind>

        <Attribute itsName="date">
            <type>@core/types/Date</type>
            <cardinality>Single</cardinality>
        </Attribute>

    </Schema>

Non-schema items will probably live in a separate file, and defining these items could look like this:

<Data>
   <Item itsName="AppsMeeting" itsKind="@this/CalendarEvent">
      <set attr="date">2004/04/26</set>
      <set attr="participants">MorgenSagen</set>
   </Item>
   <Item itsName="MorgenSagen" itsKind="@cm/contacts/Contact">
      <set attr="First">Morgen</set>
      <set attr="Last">Sagen</set>
   </Item>
</Data>