Re: extensibility of role/class/property/rel

Apologies for continuing this digressive sub-thread.

The initial security markup idea has been addressed in other forks.

But the misconceptions aired here have long beards, so somehow
I feel compelled to address them.

To begin with,

<quote
cite="">
The whole point of QNames is disambiguation, not interoperability.
</quote>

There's a hoary misconception if I ever saw one.

True, QNames were introduced in the Namespaces in XML Recommendation,
where it says that the prefixes that qualify QNames are for disambiguation.
There is no other omnibus semantic for the prefixes.

That doesn't change the fact that the qualified *names* so disambiguated
are about whatever the names thus distinguished are about in their respective
namespaces.  The Namespaces Rec places no limits on the semantics
of the names disambiguated by these prefixes.   It just doesn't set any
higher floor on their semantics.

The XML+namespaces generic processing of a document instance can be
completed without using the prefixes for anything but disambiguation.  But
that does not say that a compound document which employs QNames after
the manner of Namespaces in XML has been carried to completion at that
point.  There is a lot of namespace-dependent processing yet to go.

*The point of disambiguation* in QNames is to preserve the interoperability
that is afforded by the namespace-local names.

.. to continue with the recent discourse...

At 10:54 AM +0900 8/23/06, Karl Dubost wrote:
>Hi Mark,
>
>Le 22 août 06 à 18:01, Mark Birbeck a écrit :
>>Karl,
>>
>>>but the issue, I have raised is about the second aspects, which is
>>>the mechanism to prefetch values and their definitions in a user
>>>agents. The same way, it is possible to fetch DTD, schemas, etc and
>>>do something with them because the software knows the grammar for
>>>reading a DTD or schema
>>
>>If I understand you correctly, you are saying that behaviour can be
>>defined using RDF, and this RDF can be retrieved at run-time based on
>>the use of @role.
>
>Not exactly and not necessary RDF, but it's one possibility.
>Restating the issue:
>
>When someone, an organization, a group want to define a vocabulary 
>for property, role, class, etc to be used in XHTML 2.0
>
>	1. There must be a file with the values and their associate 
>definitions somewhere on the Web.
>	2. There must be an *interoperable* and *defined* mechanism 
>to load the values and their definitions in a software.
>
>It is not necessary the software for the software to understand the 
>meaning of the values or to have a specific behaviour for each 
>values.

Now we are making progress. That is how you perceive "the issue."
That framing of the issue doesn't suffice, however, either for the
security issue that started this thread, or for access to rich
internet applications.

The capability that you assert as "the issue" here would indeed
in many circumstances be value added. But to say at the outset
that this increment of value added is all that is appropriate to add
is, in my understanding, unjustified.

For example, look at how far this thread has drifted. Clearly
"security markup" doesn't merit that epithet unless it has very
reliable implications for system behavior.

Likewise, in the sub-topic of "access to interactive widgets" which
is a significant part of the 'roadmap' work in PFWG, there are
behavior conventions that are part of the existing understanding
between Assistive Technology and mainstream installed applications
that are captured in the access APIs. Creating markup that keys the
binding of web applications to those APIs clearly has behavioral
connotations that are inherited from the existing community
agreements at the API level. We do our customers disservice if we
pretend the behavior aspect is not part of the deal.

I think we have to go back to Noah's mantra of "partial
understanding." The metadata can and should shift the frontier of the
machine's [partial] understanding of the pragmatic semantics. Even
'though it still won't get it all.

>But it is important that the user of the software can have access to 
>the prose defining of the values,

This assumption that the definition is prose and not literate
programming is an arbitrary limitation of the possible value-add of
the metadata. For example, to see why this is an anti-socially
discriminatory limitation, read Lisa Seeman's copious output on the
values of concept coding in addressing the needs of those with
cognitive disabilities, such as

http://www.w3.org/WAI/PF/usage/languageUsageAndAccess.html

I fully recognize that the simple pattern of a machinable link to
human-able documentation is frequently all we can provide in
mitigating access barriers. But this does not equal an a-priori
"requirement" that is limited to that pattern. We need to be
designing in a space that opens the door to more machine initiative
in affording assistance than that pattern allows.

Al

>so developers do not have to hardcode all possible values and their 
>definitions that groups could define.
>The intent is to really:
>	1. make the life of developers easier
>	2. promote the usability of vocabularies
>	3. promote the practice of well defined vocabularies
>
>>If so, I agree with you 110%. That has been my
>>'dream', so to speak, since even before I got involved in the HTML WG.
>>;) However...as Shane has pointed out, what the group has been very
>>careful to do, is not *mandate* this approach.
>
>	HTML 4.01 made possible to have "alt" attributes, and "title" 
>attributes, which gives more information about an information given 
>in a document. It is exactly the same kind of approach.
>	It has also accessibility and usability benefits for people 
>authoring documents.
>
>Example: Use case scenario in HTML 4.01
>
>	A Web page author wants to add contact information on a Web 
>page. The authoring tool has downloaded the value contained in 
>http://www.w3.org/2006/03/hcard
>
>Š
>    <dt id="vcard">vcard</dt>
>     <dd>A container for the rest of the class names defined in this 
>XMDP profile.
>      See <a href="../../2002/12/cal/rfc2426#sec1.">section 1. of RFC 2426</a>.
>     </dd>
>Š
>
>And presents to the author a list of values and their associated 
>definitions, then the author can choose among these values.
>
>Another benefit is that the authoring can have up to date 
>definitions if these ones are changing slightly.
>
>>I think we've gone about as far as we can at this stage of the
>>language's development by adding the necessary hooks for such
>>functionality--@role, RDFa, and so on.
>
>What kind of hooks would help to achieve the scenario described 
>above? That would be very interesting indeed.
>
>>The next phase is to let people
>>use it, and see what emerges. Taxonomies like the one Al refers to
>>will begin to emerge, and then we can start looking at how we define
>>the features of those taxonomies, how we locate them, and so on. But
>>it would be premature to try to define this now, since we just don't
>>have the experience. (And that definition need not be in XHTML 2
>>anyway, but should be a separate spec.)
>
>It could be definitely a note ala
>http://www.w3.org/TR/xml-stylesheet/
>
>The thing is that it is possible to call a stylesheet, there's the 
>mechanism to do that. Is there a mechanism to tie the extension of 
>values of roles, class, etc.
>
>>So, the state of play is that we have a mechanism that can be used in
>>a many ways...we have a 'hook'. This hook could be used simply as a
>>container for a unique cookie that a browser or some server process
>>understands inately (the QName as identifier), or the hook could point
>>to some data to be retrieved and used by a process, such as a
>>server-side transformation or dynamically in the browser itself to
>>control behaviour (the QName as URI). But at the moment implementers
>>can choose how to use it.
>
>The hook is? namespace URI?
>
>
>
>--
>Karl Dubost - http://www.w3.org/People/karl/
>W3C Conformance Manager, QA Activity Lead
>   QA Weblog - http://www.w3.org/QA/
>      *** Be Strict To Be Cool ***

Received on Wednesday, 23 August 2006 18:56:49 UTC