Re: [Laszlo-dev] not putting names of dataset so many places

[Jim Grandy]

I'm sorry - I've been misusing the term 'axis'. In the XPath spec (http://www.w3.org/TR/xpath), 'axis' refers to "the tree relationship between the nodes selected by the location step and the context node", which is a local relation and unrelated to our "local:" prefix. The "local:name:" prefix in our XPath implementation doesn't exist in the XPath spec as far as I know, but the "name:" part at least has precedent. (See e.g. http://tinyurl.com/kct49.) If I had to make up a name for this, I'd call the "name:" portion the "document selector", with the "local:" prefix the "scope selector". The proposal is to add a "global:" selector. Adam points out that nonlocal datasets are stored in a separate dictionary already, in addition to the global/canvas name binding. Why do we need this? Would we need it if we have a "global:" scope selector? jim On May 1, 2006, at 3:18 PM, Jim Grandy wrote: That's what @id would do -- just like with any other use of @id, it   would register the dataset in the global namespace (and the canvas   one as well, since that's our practice). On May 1, 2006, at 3:13 PM, Adam Wolff wrote: I'm just saying that all the non-local datasets need to be identified somewhere so that their names can be looked up to support the   deprecated behavior. On May 1, Jim Grandy wrote: The idea is that any attribute xpath="foo:/" is implicitly really   this: xpath="global:foo:/". We'd introduce the "global:" so that the idiom could be made   explicit. Then, in the first release, your example would be legal, but would   really mean: <dataset name="foo" id="foo"/> <!-- elsewhere --> <datapointer xpath="global:foo:/"/> In the next release, perhaps, it would still be legal but would   trigger a compiler warning. Then in a final release, it would no longer be legal. You'd have   to write the explicit form. This introduces some inconvenience for folks used to using global   datasets, but the benefit would be that there'd be more symmetry between   local and global datasets. I think the learnability would be better too,   especially with a more data-driven revision of the components. I'm not too attached to the idea of making the "local:" axis the   default. Quite possibly it would be better to require that they both be   explicit. jim On May 1, 2006, at 2:54 PM, Adam Wolff wrote: do you want to change this? <dataset name="foo" <!-- elsewhere --> <datapaointer xpath="foo:/"/> If not, you need someplace (even hidden) where parsed xpaths can   look for named datasets. A On May 1, Jim Grandy wrote: Yes, it would be an incompatible change. We could deprecate implicit-global in 4.0 and either remove or switch the default in a later release. What do you think of the proposal otherwise? Should we write it   up more formally? On May 1, 2006, at 1:56 PM, Henry Minsky wrote: Swapping the default for the scope of the dataset name in the xpath query from global to local would be a pretty incompatible change in terms of existing code, I dunno if  that would be a 4.0 kind of thing or not. On 5/1/06, John Sundman <[EMAIL PROTECTED]> wrote: OK. if this is going into 3.3 I need to get right on it. Just to be sure I understand this, can I see some examples please? jrs On May 1, 2006, at 3:58 PM, Jim Grandy wrote: I'd be in favor of the following: - add a 'global:' axis to match the 'local:' axis - force use of @id attribute for global datasets -- that is,   don't register in global/canvas namespace at all unless @id is given We could add the 'global:' axis in 3.3 with declaration   without @id deprecated in that release, and then require @id for global   datasets in 4.0. We'd also make 'global:' the default in 3.3, and   'local:' (or neither) the default in 4.0. I think this would be the cleanest and simplest -- @id is how you namebind in global namespaace, period. Just like HTML/CSS. Also, making 'local:' axis the default would match our move in the components to more data-driven design -- local datasets should   be more common in 4.0 than global datasets. I haven't thought deeply about the compat issues here, but I   think this is pretty straightforward. jim On May 1, 2006, at 9:59 AM, Henry Minsky wrote: Tucker asked at one point if we could cut down the number of different places we put in a pointer to a dataset. We've got these three in the LzDataset.setName method:    if ( this.oncanvas ){        global[ name ] = this;        canvas[ name ] = this;    } else {        // it's local - add the parent's UID        name = this.parent.getUID() + '.' + name;    }    canvas.datasets[name] = this; Would this be a good time to clean this up a little and pick   one (or two) of the these choices? -- Henry Minsky Software Architect [EMAIL PROTECTED] _______________________________________________ Laszlo-dev mailing list Laszlo-dev@openlaszlo.org http://www.openlaszlo.org/mailman/listinfo/laszlo-dev _______________________________________________ Laszlo-dev mailing list Laszlo-dev@openlaszlo.org http://www.openlaszlo.org/mailman/listinfo/laszlo-dev --  Henry Minsky Software Architect [EMAIL PROTECTED] _______________________________________________ Laszlo-dev mailing list Laszlo-dev@openlaszlo.org http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev@openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev