Re: ISSUE-41/ACTION-97 decentralized-extensibility

[Philip Taylor-5]

(Removed from public-html to avoid distracting the thread)

Jonas Sicking wrote:

> One of the problems with namespacing a'la XML Namespaces is that an
> objects identifing name isn't a single string, it's a tuple. Everyone
> has to lug around two separate values, localName and namespaceURI.
> (Many times implementations have to lug around three values,
> localName, namespaceURI, and prefix).
>
> RDF has not chosen to use this. Instead it concatenates the expanded
> prefix together with the localName-esq value in order to form a single
> string. Each part of an RDF triplet, subject, predicate and object, is
> identified by a single string (though in the case of object there's
> additionally a datatype). The triplet does not consist of 3 string
> tuples.
>
> So while RDFa keeps one (what I perceive) complexity of XML
> Namespaces, the use of prefixes, it has done away with another
> complexity, namely the use of string tuples as identifiers.

This seems to be mixing RDF and its serialisations a little.

To be slightly more precise: RDF (as in
http://www.w3.org/TR/rdf-concepts/) does not have any concept of
prefixes or localNames or namespaces at all, it just has single strings.
It does not do any concatenation.

Many *serialisations* of RDF, like RDF/XML and RDFa and Turtle, do have
the concept of prefixes and localNames and namespaces, and they get
mapped onto the RDF data model (usually with concatenation), at which
point they're necessarily just strings. Some other serialisations of
RDF, like NTriples and HTML5 microdata, don't have the namespace concept.

So it's RDF (not RDFa) that has done away with string tuples as
identifiers, and RDFa CURIEs (not RDF) that provide a mapping from
namespaceURI/localName tuples to RDF's strings.

Anyway, I don't think this matters much to the general point, that
(given xmlns:foo=foo and xmlns:foob=foob) the identifiers written as
"foo:bar" and "foob:ar" are distinct in XML Namespaces but equivalent in
RDFa.

--
Philip Taylor
pjt47@...

[Shelley Powers]

I'd reply to your comments,  Henri, but evidently my emails are not
welcome, and are considered, now what were the words? Oh yes,
"shrillness" and "hyperbole".

Interesting how "shrill" is used when women communicate in tech
discussions. About as interesting as statements about it being more cost
effective just to hire someone from a third world country to read to the
blind, rather than implement accessibility for the web.

Shelley


Henri Sivonen wrote:

> On Oct 2, 2009, at 19:41, Shelley Powers wrote:
>
>> Henri Sivonen wrote:
>>>
>>>>>
>>>>> It seems to me this needs to be assessed in the context of use
>>>>> cases. It would help to know what kind of state editor vendors
>>>>> would like to save, what mechanisms they use now and what state
>>>>> saving they recall they have foregone due to lack of syntax in HTML.
>>>>>
>>>> A use case was provided. I added to it. If you don't find it
>>>> sufficient, feel free to reject.
>>>
>>> A general class of use cases was provided but no concrete cases
>>> that'd allow solutions to be evaluated.
>>
>> What do you mean by "concrete"?
>
> A specific example of what kind of state an HTML editor tool wants to
> save.
>
>> No, I didn't say that RDFa is a decentralized extensibility, by itself.
>
> OK. For clarity, are you saying that RDFa *isn't* "a decentralized
> extensibility"?
>
>>>> And that is a good form of openness, though as you say, not without
>>>> its own challenges. But, that's more of a application extensibility
>>>> rather than a markup extensibility. Yes, HTML has object, but
>>>> that's so browsers could be extended with additional functionality.
>>>>
>>>> This proposal is talking about extensibility at the core level, in
>>>> the markup, itself.
>>>>
>>>> Frankly, two different things.
>>> [...]
>>>> I'm sorry, but I don't understand what you're saying here. Could
>>>> you rephrase it?
>>>
>>> How is an ActiveX control that hooks to <object> and a byte stream
>>> different *from the user point of view* than an ActiveX control that
>>> hooks into "custom tags" in IE? In both cases, there's content out
>>> there that you can't read in your browser without installing an
>>> additional piece of software, and the piece of software isn't
>>> available for all browsers on all platforms.
>>
>> Henri, sorry, I'm probably being particularly dense today, but I'm
>> not sure how this is related to the Microsoft proposal.
>
> IE today allows ActiveX controls implement rendering of "custom tag"
> subtrees. I'm interested in understanding the relationship of that
> feature to the proposal.
>
>>> How does the Web become better if additional pieces of native-code
>>> software hook to the DOM in addition to hooking to <object>/<embed>
>>> and a byte stream?
>>>
>> Native code software?
>
> Code implemented as instructions native to the CPU. The way NPAPI
> plug-ins and ActiveX controls are implemented.
>
>> Well, when it comes to namespaced elements in SVG in an HTML
>> document, I can see immediate benefit to JS libraries accessing those
>> elements.
>
> SVG is not a "decentralized" extension to HTML, AFAICT. It's
> centralized right here at the W3C together with HTML.
>
>> So, let's ignore the implementation details and focus on your
>> concerns about decentralized extensibility. Is your concern, then,
>> that no one has provided an argument you can agree with that
>> decentralized extensibility is needed? You did question Tony's
>> proposal, but I didn't see you question the assertions in the
>> proposal about the need for extensibility, only specific use cases.
>> What exactly do you have against decentralized extensibility? If you
>> can list out the specifics, perhaps we could discuss them, one by one.
>
> I can't agree or disagree on whether 'decentralized extensibility' is
> needed and I can't say what I have (if anything) against it without
> knowing what 'decentralized extensibility' is. It would be helpful to
> have a necessary and sufficient definition of what language
> characteristics constitute 'decentralized extensibility'.
>
> Is the set of characteristics a proper subset of the characteristics
> of Namespaces in XML or are the sets one and the same?
>
>>> * When content depends on language extensions that need client
>>> software extensions to process, the ability of users to read Web
>>> content is harmed in software/hardware environments for which the
>>> client software extensions aren't available.
>>>
>>
>> I would say that a significant proportion of HTML5 falls into the
>> category of needing implementation that isn't universally available
>> in all environments.
>
> As far as I know, the HTML5 spec is royalty-free and it's being
> implemented in multiple engines some of which are Open Source. There
> doesn't seem to be any one party controlling the availability of an
> HTML5 implementation for a given computing platform.
>
>>> * Working with string tuple identifiers is harder than working with
>>> simple string identifiers.
>>
>> Again, this has nothing to do with your concern about decentralized
>> extensibility. I think we should focus on the most significant
>> concern, address it, and then move on to implementation once past
>> that initial concern. Don't you think?
>
> It depends on whether 'decentralized extensibility' is synonymous with
> Namespaces.
>
>>> * Prefix-based indirection (where the prefix expands to something as
>>> opposed to being just a naming convention) confuses people.
>>>
>> Again, outside of the initial concern about decentralized
>> extensibility as a whole.
>
> It depends on whether 'decentralized extensibility' is synonymous with
> Namespaces.
>

[rubys]

Shelley Powers wrote:
> I'd reply to your comments,  Henri, but evidently my emails are not
> welcome, and are considered, now what were the words? Oh yes,
> "shrillness" and "hyperbole".

While I condemn such statements, I haven't seen them from Henri.

And while your statement may or may not be welcome on WHATWG mailing
lists and IRC channels, let me assure you that your emails are welcome
on W3C provided venues.

> Interesting how "shrill" is used when women communicate in tech
> discussions. About as interesting as statements about it being more cost
> effective just to hire someone from a third world country to read to the
> blind, rather than implement accessibility for the web.

"Interesting" is a polite word for it.  I can think of a number of other
words.

> Shelley
>
>
> Henri Sivonen wrote:
>> On Oct 2, 2009, at 19:41, Shelley Powers wrote:
>>
>>> Henri Sivonen wrote:
>>>>
>>>>>>
>>>>>> It seems to me this needs to be assessed in the context of use
>>>>>> cases. It would help to know what kind of state editor vendors
>>>>>> would like to save, what mechanisms they use now and what state
>>>>>> saving they recall they have foregone due to lack of syntax in HTML.
>>>>>>
>>>>> A use case was provided. I added to it. If you don't find it
>>>>> sufficient, feel free to reject.
>>>>
>>>> A general class of use cases was provided but no concrete cases
>>>> that'd allow solutions to be evaluated.
>>>
>>> What do you mean by "concrete"?
>>
>> A specific example of what kind of state an HTML editor tool wants to
>> save.
>>
>>> No, I didn't say that RDFa is a decentralized extensibility, by itself.
>>
>> OK. For clarity, are you saying that RDFa *isn't* "a decentralized
>> extensibility"?
>>
>>>>> And that is a good form of openness, though as you say, not without
>>>>> its own challenges. But, that's more of a application extensibility
>>>>> rather than a markup extensibility. Yes, HTML has object, but
>>>>> that's so browsers could be extended with additional functionality.
>>>>>
>>>>> This proposal is talking about extensibility at the core level, in
>>>>> the markup, itself.
>>>>>
>>>>> Frankly, two different things.
>>>> [...]
>>>>> I'm sorry, but I don't understand what you're saying here. Could
>>>>> you rephrase it?
>>>>
>>>> How is an ActiveX control that hooks to <object> and a byte stream
>>>> different *from the user point of view* than an ActiveX control that
>>>> hooks into "custom tags" in IE? In both cases, there's content out
>>>> there that you can't read in your browser without installing an
>>>> additional piece of software, and the piece of software isn't
>>>> available for all browsers on all platforms.
>>>
>>> Henri, sorry, I'm probably being particularly dense today, but I'm
>>> not sure how this is related to the Microsoft proposal.
>>
>> IE today allows ActiveX controls implement rendering of "custom tag"
>> subtrees. I'm interested in understanding the relationship of that
>> feature to the proposal.
>>
>>>> How does the Web become better if additional pieces of native-code
>>>> software hook to the DOM in addition to hooking to <object>/<embed>
>>>> and a byte stream?
>>>>
>>> Native code software?
>>
>> Code implemented as instructions native to the CPU. The way NPAPI
>> plug-ins and ActiveX controls are implemented.
>>
>>> Well, when it comes to namespaced elements in SVG in an HTML
>>> document, I can see immediate benefit to JS libraries accessing those
>>> elements.
>>
>> SVG is not a "decentralized" extension to HTML, AFAICT. It's
>> centralized right here at the W3C together with HTML.
>>
>>> So, let's ignore the implementation details and focus on your
>>> concerns about decentralized extensibility. Is your concern, then,
>>> that no one has provided an argument you can agree with that
>>> decentralized extensibility is needed? You did question Tony's
>>> proposal, but I didn't see you question the assertions in the
>>> proposal about the need for extensibility, only specific use cases.
>>> What exactly do you have against decentralized extensibility? If you
>>> can list out the specifics, perhaps we could discuss them, one by one.
>>
>> I can't agree or disagree on whether 'decentralized extensibility' is
>> needed and I can't say what I have (if anything) against it without
>> knowing what 'decentralized extensibility' is. It would be helpful to
>> have a necessary and sufficient definition of what language
>> characteristics constitute 'decentralized extensibility'.
>>
>> Is the set of characteristics a proper subset of the characteristics
>> of Namespaces in XML or are the sets one and the same?
>>
>>>> * When content depends on language extensions that need client
>>>> software extensions to process, the ability of users to read Web
>>>> content is harmed in software/hardware environments for which the
>>>> client software extensions aren't available.
>>>>
>>>
>>> I would say that a significant proportion of HTML5 falls into the
>>> category of needing implementation that isn't universally available
>>> in all environments.
>>
>> As far as I know, the HTML5 spec is royalty-free and it's being
>> implemented in multiple engines some of which are Open Source. There
>> doesn't seem to be any one party controlling the availability of an
>> HTML5 implementation for a given computing platform.
>>
>>>> * Working with string tuple identifiers is harder than working with
>>>> simple string identifiers.
>>>
>>> Again, this has nothing to do with your concern about decentralized
>>> extensibility. I think we should focus on the most significant
>>> concern, address it, and then move on to implementation once past
>>> that initial concern. Don't you think?
>>
>> It depends on whether 'decentralized extensibility' is synonymous with
>> Namespaces.
>>
>>>> * Prefix-based indirection (where the prefix expands to something as
>>>> opposed to being just a naming convention) confuses people.
>>>>
>>> Again, outside of the initial concern about decentralized
>>> extensibility as a whole.
>>
>> It depends on whether 'decentralized extensibility' is synonymous with
>> Namespaces.
>>
>
>

[Paul Cotton]

I agree completely with Sam's comments.  

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: [phone] Fax: [phone]


-----Original Message-----
From: Sam Ruby [mailto:rubys@...]
Sent: Friday, October 02, 2009 4:06 PM
To: Shelley Powers
Cc: Henri Sivonen; www-archive; Adrian Bateman; Maciej Stachowiak; Paul Cotton
Subject: Re: ISSUE-41/ACTION-97 decentralized-extensibility

Shelley Powers wrote:
> I'd reply to your comments,  Henri, but evidently my emails are not
> welcome, and are considered, now what were the words? Oh yes,
> "shrillness" and "hyperbole".

While I condemn such statements, I haven't seen them from Henri.

And while your statement may or may not be welcome on WHATWG mailing
lists and IRC channels, let me assure you that your emails are welcome
on W3C provided venues.

> Interesting how "shrill" is used when women communicate in tech
> discussions. About as interesting as statements about it being more cost
> effective just to hire someone from a third world country to read to the
> blind, rather than implement accessibility for the web.

"Interesting" is a polite word for it.  I can think of a number of other
words.

> Shelley
>
>
> Henri Sivonen wrote:
>> On Oct 2, 2009, at 19:41, Shelley Powers wrote:
>>
>>> Henri Sivonen wrote:
>>>>
>>>>>>
>>>>>> It seems to me this needs to be assessed in the context of use
>>>>>> cases. It would help to know what kind of state editor vendors
>>>>>> would like to save, what mechanisms they use now and what state
>>>>>> saving they recall they have foregone due to lack of syntax in HTML.
>>>>>>
>>>>> A use case was provided. I added to it. If you don't find it
>>>>> sufficient, feel free to reject.
>>>>
>>>> A general class of use cases was provided but no concrete cases
>>>> that'd allow solutions to be evaluated.
>>>
>>> What do you mean by "concrete"?
>>
>> A specific example of what kind of state an HTML editor tool wants to
>> save.
>>
>>> No, I didn't say that RDFa is a decentralized extensibility, by itself.
>>
>> OK. For clarity, are you saying that RDFa *isn't* "a decentralized
>> extensibility"?
>>
>>>>> And that is a good form of openness, though as you say, not without
>>>>> its own challenges. But, that's more of a application extensibility
>>>>> rather than a markup extensibility. Yes, HTML has object, but
>>>>> that's so browsers could be extended with additional functionality.
>>>>>
>>>>> This proposal is talking about extensibility at the core level, in
>>>>> the markup, itself.
>>>>>
>>>>> Frankly, two different things.
>>>> [...]
>>>>> I'm sorry, but I don't understand what you're saying here. Could
>>>>> you rephrase it?
>>>>
>>>> How is an ActiveX control that hooks to <object> and a byte stream
>>>> different *from the user point of view* than an ActiveX control that
>>>> hooks into "custom tags" in IE? In both cases, there's content out
>>>> there that you can't read in your browser without installing an
>>>> additional piece of software, and the piece of software isn't
>>>> available for all browsers on all platforms.
>>>
>>> Henri, sorry, I'm probably being particularly dense today, but I'm
>>> not sure how this is related to the Microsoft proposal.
>>
>> IE today allows ActiveX controls implement rendering of "custom tag"
>> subtrees. I'm interested in understanding the relationship of that
>> feature to the proposal.
>>
>>>> How does the Web become better if additional pieces of native-code
>>>> software hook to the DOM in addition to hooking to <object>/<embed>
>>>> and a byte stream?
>>>>
>>> Native code software?
>>
>> Code implemented as instructions native to the CPU. The way NPAPI
>> plug-ins and ActiveX controls are implemented.
>>
>>> Well, when it comes to namespaced elements in SVG in an HTML
>>> document, I can see immediate benefit to JS libraries accessing those
>>> elements.
>>
>> SVG is not a "decentralized" extension to HTML, AFAICT. It's
>> centralized right here at the W3C together with HTML.
>>
>>> So, let's ignore the implementation details and focus on your
>>> concerns about decentralized extensibility. Is your concern, then,
>>> that no one has provided an argument you can agree with that
>>> decentralized extensibility is needed? You did question Tony's
>>> proposal, but I didn't see you question the assertions in the
>>> proposal about the need for extensibility, only specific use cases.
>>> What exactly do you have against decentralized extensibility? If you
>>> can list out the specifics, perhaps we could discuss them, one by one.
>>
>> I can't agree or disagree on whether 'decentralized extensibility' is
>> needed and I can't say what I have (if anything) against it without
>> knowing what 'decentralized extensibility' is. It would be helpful to
>> have a necessary and sufficient definition of what language
>> characteristics constitute 'decentralized extensibility'.
>>
>> Is the set of characteristics a proper subset of the characteristics
>> of Namespaces in XML or are the sets one and the same?
>>
>>>> * When content depends on language extensions that need client
>>>> software extensions to process, the ability of users to read Web
>>>> content is harmed in software/hardware environments for which the
>>>> client software extensions aren't available.
>>>>
>>>
>>> I would say that a significant proportion of HTML5 falls into the
>>> category of needing implementation that isn't universally available
>>> in all environments.
>>
>> As far as I know, the HTML5 spec is royalty-free and it's being
>> implemented in multiple engines some of which are Open Source. There
>> doesn't seem to be any one party controlling the availability of an
>> HTML5 implementation for a given computing platform.
>>
>>>> * Working with string tuple identifiers is harder than working with
>>>> simple string identifiers.
>>>
>>> Again, this has nothing to do with your concern about decentralized
>>> extensibility. I think we should focus on the most significant
>>> concern, address it, and then move on to implementation once past
>>> that initial concern. Don't you think?
>>
>> It depends on whether 'decentralized extensibility' is synonymous with
>> Namespaces.
>>
>>>> * Prefix-based indirection (where the prefix expands to something as
>>>> opposed to being just a naming convention) confuses people.
>>>>
>>> Again, outside of the initial concern about decentralized
>>> extensibility as a whole.
>>
>> It depends on whether 'decentralized extensibility' is synonymous with
>> Namespaces.
>>
>
>

[Maciej Stachowiak]

I agree with Sam. In particular:

1) Calling a participant "shrill" invokes gender stereotypes in a way  
that is completely inappropriate.
2) Your recent emails on distributed extensibility are useful  
technical input and are welcome on the HTML WG mailing list, as far as  
I'm concerned.
3) I think you and Henri should continue your discussion on the list  
as long as both of you can keep it level-headed and about the issues.  
So far, I believe both of you have.

Regards,
Maciej

On Oct 2, 2009, at 1:06 PM, Sam Ruby wrote:

> Shelley Powers wrote:
>> I'd reply to your comments,  Henri, but evidently my emails are not  
>> welcome, and are considered, now what were the words? Oh yes,  
>> "shrillness" and "hyperbole".
>
> While I condemn such statements, I haven't seen them from Henri.
>
> And while your statement may or may not be welcome on WHATWG mailing
> lists and IRC channels, let me assure you that your emails are  
> welcome on W3C provided venues.
>
>> Interesting how "shrill" is used when women communicate in tech  
>> discussions. About as interesting as statements about it being more  
>> cost effective just to hire someone from a third world country to  
>> read to the blind, rather than implement accessibility for the web.
>
> "Interesting" is a polite word for it.  I can think of a number of  
> other words.
>
>> Shelley
>> Henri Sivonen wrote:
>>> On Oct 2, 2009, at 19:41, Shelley Powers wrote:
>>>
>>>> Henri Sivonen wrote:
>>>>>
>>>>>>>
>>>>>>> It seems to me this needs to be assessed in the context of use  
>>>>>>> cases. It would help to know what kind of state editor vendors  
>>>>>>> would like to save, what mechanisms they use now and what  
>>>>>>> state saving they recall they have foregone due to lack of  
>>>>>>> syntax in HTML.
>>>>>>>
>>>>>> A use case was provided. I added to it. If you don't find it  
>>>>>> sufficient, feel free to reject.
>>>>>
>>>>> A general class of use cases was provided but no concrete cases  
>>>>> that'd allow solutions to be evaluated.
>>>>
>>>> What do you mean by "concrete"?
>>>
>>> A specific example of what kind of state an HTML editor tool wants  
>>> to save.
>>>
>>>> No, I didn't say that RDFa is a decentralized extensibility, by  
>>>> itself.
>>>
>>> OK. For clarity, are you saying that RDFa *isn't* "a decentralized  
>>> extensibility"?
>>>
>>>>>> And that is a good form of openness, though as you say, not  
>>>>>> without its own challenges. But, that's more of a application  
>>>>>> extensibility rather than a markup extensibility. Yes, HTML has  
>>>>>> object, but that's so browsers could be extended with  
>>>>>> additional functionality.
>>>>>>
>>>>>> This proposal is talking about extensibility at the core level,  
>>>>>> in the markup, itself.
>>>>>>
>>>>>> Frankly, two different things.
>>>>> [...]
>>>>>> I'm sorry, but I don't understand what you're saying here.  
>>>>>> Could you rephrase it?
>>>>>
>>>>> How is an ActiveX control that hooks to <object> and a byte  
>>>>> stream different *from the user point of view* than an ActiveX  
>>>>> control that hooks into "custom tags" in IE? In both cases,  
>>>>> there's content out there that you can't read in your browser  
>>>>> without installing an additional piece of software, and the  
>>>>> piece of software isn't available for all browsers on all  
>>>>> platforms.
>>>>
>>>> Henri, sorry, I'm probably being particularly dense today, but  
>>>> I'm not sure how this is related to the Microsoft proposal.
>>>
>>> IE today allows ActiveX controls implement rendering of "custom  
>>> tag" subtrees. I'm interested in understanding the relationship of  
>>> that feature to the proposal.
>>>
>>>>> How does the Web become better if additional pieces of native-
>>>>> code software hook to the DOM in addition to hooking to <object>/
>>>>> <embed> and a byte stream?
>>>>>
>>>> Native code software?
>>>
>>> Code implemented as instructions native to the CPU. The way NPAPI  
>>> plug-ins and ActiveX controls are implemented.
>>>
>>>> Well, when it comes to namespaced elements in SVG in an HTML  
>>>> document, I can see immediate benefit to JS libraries accessing  
>>>> those elements.
>>>
>>> SVG is not a "decentralized" extension to HTML, AFAICT. It's  
>>> centralized right here at the W3C together with HTML.
>>>
>>>> So, let's ignore the implementation details and focus on your  
>>>> concerns about decentralized extensibility. Is your concern,  
>>>> then, that no one has provided an argument you can agree with  
>>>> that decentralized extensibility is needed? You did question  
>>>> Tony's proposal, but I didn't see you question the assertions in  
>>>> the proposal about the need for extensibility, only specific use  
>>>> cases. What exactly do you have against decentralized  
>>>> extensibility? If you can list out the specifics, perhaps we  
>>>> could discuss them, one by one.
>>>
>>> I can't agree or disagree on whether 'decentralized extensibility'  
>>> is needed and I can't say what I have (if anything) against it  
>>> without knowing what 'decentralized extensibility' is. It would be  
>>> helpful to have a necessary and sufficient definition of what  
>>> language characteristics constitute 'decentralized extensibility'.
>>>
>>> Is the set of characteristics a proper subset of the  
>>> characteristics of Namespaces in XML or are the sets one and the  
>>> same?
>>>
>>>>> * When content depends on language extensions that need client  
>>>>> software extensions to process, the ability of users to read Web  
>>>>> content is harmed in software/hardware environments for which  
>>>>> the client software extensions aren't available.
>>>>>
>>>>
>>>> I would say that a significant proportion of HTML5 falls into the  
>>>> category of needing implementation that isn't universally  
>>>> available in all environments.
>>>
>>> As far as I know, the HTML5 spec is royalty-free and it's being  
>>> implemented in multiple engines some of which are Open Source.  
>>> There doesn't seem to be any one party controlling the  
>>> availability of an HTML5 implementation for a given computing  
>>> platform.
>>>
>>>>> * Working with string tuple identifiers is harder than working  
>>>>> with simple string identifiers.
>>>>
>>>> Again, this has nothing to do with your concern about  
>>>> decentralized extensibility. I think we should focus on the most  
>>>> significant concern, address it, and then move on to  
>>>> implementation once past that initial concern. Don't you think?
>>>
>>> It depends on whether 'decentralized extensibility' is synonymous  
>>> with Namespaces.
>>>
>>>>> * Prefix-based indirection (where the prefix expands to  
>>>>> something as opposed to being just a naming convention) confuses  
>>>>> people.
>>>>>
>>>> Again, outside of the initial concern about decentralized  
>>>> extensibility as a whole.
>>>
>>> It depends on whether 'decentralized extensibility' is synonymous  
>>> with Namespaces.
>>>
>
>
>
>

[James Graham-8]

> 1) Calling a participant "shrill" invokes gender stereotypes in a way  
> that is completely inappropriate.

Since this is a word that I used on irc, I feel I should respond.

I did not imagine that my choice of words would invoke any form of
gender stereotyping. I don't know if this is because of my own naivety
or some cultural difference in the use of language. In any case it seems
that I was mistaken. In light of this, I apologise for any offense that
I have caused to Shelley or anyone else.

[Shelley Powers]

James Graham wrote:

>> 1) Calling a participant "shrill" invokes gender stereotypes in a way  
>> that is completely inappropriate.
>>    
>
> Since this is a word that I used on irc, I feel I should respond.
>
> I did not imagine that my choice of words would invoke any form of
> gender stereotyping. I don't know if this is because of my own naivety
> or some cultural difference in the use of language. In any case it seems
> that I was mistaken. In light of this, I apologise for any offense that
> I have caused to Shelley or anyone else.
>
>  

Thank you for the apology.

I understand about cultural differences. Wordnik has good coverage on
the use of shrill when referring to another person's communication.

http://www.wordnik.com/words/shrill

Just as an FYI in the future.

Shelley