[Dev] XML namespaces in attribute values

[Katie Capps Parlante]

Hi Jeffrey,

Some comments below...

Jeffrey Harris wrote:

> Hi Katie (and anyone interested in the Data Model),
> 
> Before looking at Chandler, I'd never seen anyone use QNames in
> attribute values before, it seems like a useful idiom but potentially
> problematic for XML processors.  This lengthy thread,
> <http://aspn.activestate.com/ASPN/Mail/Message/xml-dev/1003472>, makes
> it clear that it hasn't always been accepted practice.  Actually, don't
> read that link, there's an editorial summarizing the whole discussion
> (if you're interested, you might as well not search through the Google
> haystack like I did...) <http://www.xml.com/pub/a/2002/02/06/deviant.html>.
> I'm not suggesting that you avoid using QNames in attribute values, just
> letting you know that it might look odd to some XML purists.

Thanks for the link. Indeed, I think we're comfortable with using QNames 
in attribute values in this case, weighing the various tradeoffs.

> I've been thinking about QNames because it takes a kludge in the XSL
> stylesheet to work with the existing parcel.xml files (see
> <http://cvs.osafoundation.org/index.cgi/osaf/chandler/Chandler/distrib/transforms/Attributes.xsl?rev=1.3&content-type=text/vnd.viewcvs-markup> 
> 
> and
> <http://cvs.osafoundation.org/index.cgi/osaf/chandler/Chandler/parcels/OSAF/PimSchema/parcel.xml?rev=1.10&content-type=text/vnd.viewcvs-markup> 
> 
> for those who don't have a current version on hand).
> 
> As far as I can tell, there isn't currently any mechanism in each
> parcel.xml that facilitates reflection.  That is to say, as far as I
> know, there's no statement that says "The current node (and its
> children) is the authoritative source for URI x" other than the fact
> that this file lives at that spot in the filesystem.  So when I'm
> writing an XSL transform of the schema, it's hard to know whether or not
> the node referred to by cal:startTime is defined in the current file.
> 
> Would it be possible to add a "describes" attribute to each Parcel
> element in parcel.xml so it looked like
> 
> <Parcel describes="//Parcels/OSAF/PimSchema/CalendarSchema"
>     itemName="CalendarSchema"
>         xmlns="//Schema/Core"
>         xmlns:cal="//Parcels/OSAF/PimSchema/CalendarSchema"
>         xmlns:contact="//Parcels/OSAF/PimSchema/ContactSchema">?
> 
> Then it wouldn't matter that Attribute itemName's don't live in the cal
> namespace, like they used to.

This is a reasonable request.

Here's an objection that I will get, though: If the file lives at 
/parcels/OSAF/PimSchema/CalendarSchema, why do I have to repeat its 
location in the text of the file? If I'm writing a python module, I 
don't have to declare its package, the package is inferred from the file 
system. This is an unreasonable burden on the xml author, and the 
purpose of this format at this time is to have a format for programmers 
to create repository data in text format.

We're trying to make the "uri" of the item, the "uri" of the parcel, the 
location of items/parcels in the repository, and the location of parcels 
in the filesystem consistent, so that we don't have to manage 
arbitrarily different hierarchies.

btw, I realize that "//Parcels/OSAF/PimSchema/CalendarSchema" and other 
such references should be a real uri, that will be fixed when we think 
more about remote access to the repository. Right now its easier for 
various reasons to use the repository path. It is on the agenda.

I'm inclined to go ahead and add it anyway, I'll bring it up again if I 
get strenous objection.

Cheers,
Katie