Lists Home |
Date Index |
firstname.lastname@example.org (Keith W. Boone) writes:
>Granted: Your names are clearer, and URI polution is not necessarily
>a good thing.
>Your argument is that the fundamental pattern is:
>However, my argument is that the fundamental pattern is:
>SetProperty(myBeastie, setting1, value)
I believe that you've gone up an extra and unnecesary level of
abstraction. I don't believe that your pattern is any more fundamental
than the pattern already established by the XPointer framework in
creating schemes. We could, of course, make all of the schemes into
similarly abstract patterns, using a single whatever() scheme and
letting its contents determine how
>As you have already demonstrated by creating three different specs
>that do essentially the same thing.
They do not do the same thing. You can abstract it to "they all set
context", but they all do so quite differently. You might note, for
instance, that xmlns-local() doesn't even provide a setting or a value.
And if you want to go all the way, we should likely add xmlns to the
list. How comfortable are people really going to be with:
pragma(http://www.w3.org/ns/xmlns/, xyz, http://example.com/ns/xyz)
> And we can assume that others
>will do the same. So now we have 10, 20 or even more different schemes
>to recall, each with potentially different rules for use. All to
>communicate some setting/property to the XPointer processor in some
>way. I'd much prefer one way to accomplish the same capability, with
>rules that I can remember and which don't change between properties.
I don't find remembering URIs to be any easier than remembering scheme
names. I don't typically write code of the form:
function(functionName, value, value)
I'd much prefer to write:
>The semantics of the properties are perhaps unclear, but if you have
>10 or 20 difference schemes to recall, I can make the same argument:
>The semantics of the arguments for each scheme is not regular, and is
That doesn't justify an extra layer of abstraction. Schemes are already
a substantial abstraction step up from prior practice.
>XML Parsers already use the URI mess to handle property naming, and it
>seems that the method works, ugly as it may be. If there was another
>way to handle it without URIs, would you be amenable?
No. This goes too far up the abstraction tree with or without URIs.
>Perhaps, we could agree upon an uber-specification for pragma-like
You're welcome to write one, but I would not plan to use it.
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:220.127.116.11.4.1.6320 is another possibility altogether