Nabble - w3.org - www-archive

Re: Proposed W3C Spec Conventions

2009-12-04T10:04:13Z

Hi, Folks-

Thanks for all the great feedback so far!

I've discovered the existing list spec-prod, which seems like a better
place for these discussions, so I'd ask that anyone interested in
following up further respond to spec-prod instead of www-archive.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Doug Schepers wrote (on 11/23/09 3:44 AM):

> Hi, Folks-
>
> (Forwarding and summarizing from Member-only space.)
>
> I'm not the first one to suggest this (apparently Karl tried to push
> this earlier this year), but I really think it's time we establish some
> standardized style conventions for W3C specs.
>
> I took a couple hours to pull together a proposal (attached) based on
> Karl's original along with feedback to that proposal, and conventions
> that I'm familiar with from the SVG and DOM3 Events specs; I'm not
> married to any of it, but any counter-proposals should probably stick
> with at least the level of granularity laid out here.
>
> Please see the attached, and send in counter-proposals or thoughts for
> consideration.
>
> I plan on using this (or whatever variant we all decide on) in the specs
> I'm editing (some SVG specs, DOM3 Events). I encourage others to do the
> same, and report back what works, what doesn't work, what's missing, etc.
>
> (Oh, and I'd really like to see this working with Robin Berjon's ReSpec.js:
> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html )
>
> Thanks!
> -Doug Schepers
> W3C Team Contact, SVG and WebApps \o/ WGs
>

Re: Proposed W3C Spec Conventions

2009-12-04T10:00:42Z

Hi, David-

+spec-prod

L. David Baron wrote (on 12/2/09 5:02 PM):
>
> One thing I'm not a big fan of in this proposal is the color
> conventions used for "Issue" and "Proposal" text, which swap in a
> different foreground color. I somewhat prefer the styles I've used
> a few times, e.g., in http://dbaron.org/css/intrinsic/#intrinsic ,
> which are clearly distinct, but which I find not quite as jarring.

Fair enough. It doesn't bother me, but different people have different
tastes. I imagine that if we get a real designer to lend a hand, we
will end up with better visual representations for everything than we
have right now.

> One other note is that I find the styles here:
> # The defining instance of a term is marked up like this: term.
> # Uses of that term are marked up like this.
> a bit odd, both because:
> (1) it seems odd to switch to a monospace font for something that's
> not code, and
> (2) defining instances of terms are traditionally styled in
> italics, I think.
> I would suggest styling the defining instance in italics and the
> uses as the default link styles.

Seems reasonable. Robin Berjon suggested different link underline
colors for internal vs. external links, and I like that idea, too... so,
maybe we could compromise somewhere in the middle?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

New IRC Channel #specs

2009-12-04T09:19:20Z

Hi, Folks-

I'd like to announce #specs, a new W3C IRC channel for discussing
spec-writing tools and tips:

IRC channel: #specs on irc.w3.org:6665 (that's port 6665, not the
default)

This is intended to be complementary to the spec-prod mailing list,
which is a public mailing list devoted to mechanisms for producing and
managing W3C specifications:

http://lists.w3.org/Archives/Public/spec-prod/

There seems to be a lot of recent momentum toward improving the W3C
spec-writing process, so if you're interested in that, please feel free
to join spec-prod (if you aren't there already).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

re: vCard RDF Note Update: Geo

2009-12-03T22:34:06Z

Hi all - we have had some off-list discussion and there is some consensus to keep to one namespace for the geo properties. So we will be reverting to long/lat under the vcard namespace (as xsd:floats)

The next version will reflect this....

Cheers... Renato Iannella
NICTA

iframe vs object for SVG (was: Re: Param)

2009-12-03T17:16:44Z

-public-html
+www-archive

On Mon, 30 Nov 2009 06:38:15 +0100, Maciej Stachowiak <mjs@...>
wrote:

>> Why would you recommend <iframe> instead of <object>?
>
> <object> has downsides due to the fact that it behaves differently for
> image types, types handled by plugins, and natively handled types that
> form a DOM. Which of these three modes is enabled cannot be properly
> decided until the type of a remote resource is retrieved from the
> server. This tends to cause performance and correctness issues.

The browser can be hinted of the type with the type='' attribute. It might
turn out to be incorrect, but if it's correct, I'd hope there to be no
noticeable performance difference.

> <iframe>, which is specialized for containing a natively supported DOM-
> forming document type, tends to work more reliably. It would be my
> first choice to embed either HTML or SVG.

<iframe> has a border by default, and a default size of 300x150 which the
SVG can't affect. <object> and <img> by default size themselves after the
SVG, which is a nice feature. <object> and <img> also support fallback
content for browsers that don't support SVG. SVG in <img> is not supported
in Firefox yet, though. For these reasons, my first choice would be
<object> when embedding SVG.

--
Simon Pieters
Opera Software

Re: Final Final vCard (take 3)

2009-12-02T22:26:23Z

All - latest update (taking feedback to date):

http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091203.html
http://spin.nicta.org.au/vCardRDF/ns-20091203.rdf

Cheers... Renato Iannella
NICTA

Re: Proposed W3C Spec Conventions

2009-12-02T15:20:37Z

hurumph!

Screen readers do not even naturally call out ...

On Dec 2, 2009, at 6:14 PM, Tab Atkins Jr. wrote:

On Wed, Dec 2, 2009 at 4:57 PM, Doug Schepers <schepers@...> wrote:
> I originally used , but changed it to based on the accessibility
> feedback [1] to Karl's original proposal by Gregory Rosmaita, a reader of
> W3C specs who uses a screen reader. The fact that these passages are being
> called out as somehow special (marked with specific markup and class names)
> is indicative that they are being emphasized. Could you explain why you
> think such emphasis isn't warranted or desired? Maybe I'm just missing
> something.

I just don't see those sections as being emphasized; I wouldn't use a
special tone of voice to read them out over the phone, for example.
(I would do so for the words "Note:", "Warning:", etc., which is why
 is appropriate there.)

>> If italics are desirable,
>> please switch to using an element instead. The use of 
>> within those examples is acceptable, however.
>
> (I think it's funny that the CSS WG would recommend using an old-fashioned
> styling element like ... times change, I guess. ^_^)

 ain't a styling element anymore. ^_^ It has (weak) semantics of
'this is something special, in an unspecified manner', which is
precisely what you're trying to express. It also applies a useful
styling for non-CSS user agents. (Sorry, was incorrect in my previous
email - you do indeed remove the italics and style it in another
fashion; is still an appropriate element here.)

> If you could comment on that, that might help move this issue forward. I'm
> happy to use either or , based on what works best. I'm less
> enthused about for reasons I mentioned before, but will use that if
> that's the general consensus.

Sure. I agree that is sub-optimal for this use-case; you *do*
want to call it out as vaguely special, it's just not (in my opinion)
phasized. carries the correct semantics of it being distinct
from the surrounding content.

Screenreaders may not be fully up-to-date in handling this sort of
thing, however.

> We also discussed including aural styles for these classes.

Be careful - afaik, many (most?) screenreaders ignore aural styles, as
inferring presentation from visual styles tends to be more reliable.
Just do some research before you sink any time into providing
aural-specific styles.

>> The CSS WG does not have any further comments on your proposal.
>
> Is the CSS WG likely to adopt these spec conventions [2] (assuming we can
> all come to agreement on the markup and styling)? The SVG WG has resolved
> to adopt whatever common conventions are decided upon, as have the folks
> working on the DOM3 Events spec with me.

I can't speak for the CSSWG further than the comment I gave, but I
don't personally see any particular reason why not, and suspect that
we'd be fine with it. We produce our specs through Bert Bos's
formatting script, and it shouldn't be a difficult thing to change
that to match up with the final guidelines here.

~TJ

Re: Proposed W3C Spec Conventions

2009-12-02T15:14:00Z

On Wed, Dec 2, 2009 at 4:57 PM, Doug Schepers <schepers@...> wrote:
> I originally used , but changed it to based on the accessibility
> feedback [1] to Karl's original proposal by Gregory Rosmaita, a reader of
> W3C specs who uses a screen reader. The fact that these passages are being
> called out as somehow special (marked with specific markup and class names)
> is indicative that they are being emphasized. Could you explain why you
> think such emphasis isn't warranted or desired? Maybe I'm just missing
> something.

I just don't see those sections as being emphasized; I wouldn't use a
special tone of voice to read them out over the phone, for example.
(I would do so for the words "Note:", "Warning:", etc., which is why
 is appropriate there.)

>> If italics are desirable,
>> please switch to using an element instead. The use of 
>> within those examples is acceptable, however.
>
> (I think it's funny that the CSS WG would recommend using an old-fashioned
> styling element like ... times change, I guess. ^_^)

 ain't a styling element anymore. ^_^ It has (weak) semantics of
'this is something special, in an unspecified manner', which is
precisely what you're trying to express. It also applies a useful
styling for non-CSS user agents. (Sorry, was incorrect in my previous
email - you do indeed remove the italics and style it in another
fashion; is still an appropriate element here.)

> If you could comment on that, that might help move this issue forward. I'm
> happy to use either or , based on what works best. I'm less
> enthused about for reasons I mentioned before, but will use that if
> that's the general consensus.

Sure. I agree that is sub-optimal for this use-case; you *do*
want to call it out as vaguely special, it's just not (in my opinion)
phasized. carries the correct semantics of it being distinct
from the surrounding content.

Screenreaders may not be fully up-to-date in handling this sort of
thing, however.

> We also discussed including aural styles for these classes.

Be careful - afaik, many (most?) screenreaders ignore aural styles, as
inferring presentation from visual styles tends to be more reliable.
Just do some research before you sink any time into providing
aural-specific styles.

>> The CSS WG does not have any further comments on your proposal.
>
> Is the CSS WG likely to adopt these spec conventions [2] (assuming we can
> all come to agreement on the markup and styling)? The SVG WG has resolved
> to adopt whatever common conventions are decided upon, as have the folks
> working on the DOM3 Events spec with me.

I can't speak for the CSSWG further than the comment I gave, but I
don't personally see any particular reason why not, and suspect that
we'd be fine with it. We produce our specs through Bert Bos's
formatting script, and it shouldn't be a difficult thing to change
that to match up with the final guidelines here.

~TJ

Re: Proposed W3C Spec Conventions

2009-12-02T14:57:10Z

Hi, Tab-

Thanks for your comment. Replies inline...

Tab Atkins Jr. wrote (on 12/2/09 3:20 PM):
>
> One comment - in all the inline example near the end (Note, Warning,
> etc) you use an element to mark it up, but it does not seem as if
> textual emphasis is warranted or desired.

I originally used , but changed it to based on the
accessibility feedback [1] to Karl's original proposal by Gregory
Rosmaita, a reader of W3C specs who uses a screen reader. The fact that
these passages are being called out as somehow special (marked with
specific markup and class names) is indicative that they are being
emphasized. Could you explain why you think such emphasis isn't
warranted or desired? Maybe I'm just missing something.

>If italics are desirable,
> please switch to using an element instead. The use of 
> within those examples is acceptable, however.

(I think it's funny that the CSS WG would recommend using an
old-fashioned styling element like ... times change, I guess. ^_^)

Italics are not at all what I was going for... as you see, I've used CSS
to remove the italic default for the elements... I'm really just
using them for the semantics.

I chatted with Michael Cooper of the WAI domain, and he had this to say:

[[
* tags like and are more likely to be picked up by a
screen reader as "there's something important about this"

* even though it won't get semantic meaning out of the class, at least
it knows there's something there

* that may work with but it's generally frowned on in favour of 
(which may be a philosophy issue as much as anything)

* is much less likely to be picked up by a screen reader as
"there's something important here" even with a class and styling, so
 is much less useful

* My feedback: the accessibility principle at work is "use the closest
semantic element you can, and then use CSS to refine the style to refine
the presentation of that semantic"

* The CSS WG might think is preferable because it's
semantic-neutral, but from an accessibility standpoint that's not helpful
]]

If you could comment on that, that might help move this issue forward.
I'm happy to use either or , based on what works best. I'm
less enthused about for reasons I mentioned before, but will use
that if that's the general consensus.

We also discussed including aural styles for these classes.

> The CSS WG does not have any further comments on your proposal.

Is the CSS WG likely to adopt these spec conventions [2] (assuming we
can all come to agreement on the markup and styling)? The SVG WG has
resolved to adopt whatever common conventions are decided upon, as have
the folks working on the DOM3 Events spec with me.

[1] http://lists.w3.org/Archives/Member/chairs/2009JanMar/0030.html
(Member-only link)
[2] http://www.w3.org/People/Schepers/spec-conventions.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: Proposed W3C Spec Conventions

2009-12-02T14:02:11Z

On Monday 2009-11-23 03:44 -0500, Doug Schepers wrote:

> (Forwarding and summarizing from Member-only space.)
>
> I'm not the first one to suggest this (apparently Karl tried to push
> this earlier this year), but I really think it's time we establish
> some standardized style conventions for W3C specs.
>
> I took a couple hours to pull together a proposal (attached) based
> on Karl's original along with feedback to that proposal, and
> conventions that I'm familiar with from the SVG and DOM3 Events
> specs; I'm not married to any of it, but any counter-proposals
> should probably stick with at least the level of granularity laid
> out here.
>
> Please see the attached, and send in counter-proposals or thoughts
> for consideration.

One thing I'm not a big fan of in this proposal is the color
conventions used for "Issue" and "Proposal" text, which swap in a
different foreground color. I somewhat prefer the styles I've used
a few times, e.g., in http://dbaron.org/css/intrinsic/#intrinsic ,
which are clearly distinct, but which I find not quite as jarring.

One other note is that I find the styles here:
# The defining instance of a term is marked up like this: term.
# Uses of that term are marked up like this.
a bit odd, both because:
(1) it seems odd to switch to a monospace font for something that's
not code, and
(2) defining instances of terms are traditionally styled in
italics, I think.
I would suggest styling the defining instance in italics and the
uses as the default link styles.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Re: Proposed W3C Spec Conventions

2009-12-02T12:20:59Z

> Hi, Folks-
>
> (Forwarding and summarizing from Member-only space.)
> I'm not the first one to suggest this (apparently Karl tried to push
> this earlier this year), but I really think it's time we establish some
> standardized style conventions for W3C specs.
> I took a couple hours to pull together a proposal (attached) based on
> Karl's original along with feedback to that proposal, and conventions
> that I'm familiar with from the SVG and DOM3 Events specs; I'm not
> married to any of it, but any counter-proposals should probably stick
> with at least the level of granularity laid out here.
> Please see the attached, and send in counter-proposals or thoughts for
> consideration.
>
> I plan on using this (or whatever variant we all decide on) in the specs
> I'm editing (some SVG specs, DOM3 Events). I encourage others to do the
> same, and report back what works, what doesn't work, what's missing, etc.
> (Oh, and I'd really like to see this working with Robin Berjon's ReSpec.js:
> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html )
>
> Thanks!
> -Doug Schepers
> W3C Team Contact, SVG and WebApps \o/ WGs

One comment - in all the inline example near the end (Note, Warning,
etc) you use an element to mark it up, but it does not seem as if
textual emphasis is warranted or desired. If italics are desirable,
please switch to using an element instead. The use of 
within those examples is acceptable, however.

The CSS WG does not have any further comments on your proposal.

~TJ

Re: Final Final vCard (take 2)

2009-12-01T05:37:08Z

Hi Peter - I understand the issue - perhaps we should try to fix the source (vCard 4.0 currently under development?)

What do others think?

Renato

On 1 Dec 2009, at 20:53, Peter Mika wrote:

> Hi Renato,
>
> Many thanks for this otherwise ungrateful work...
>
> Here is a small suggestion to maximize compatibility with hCard. The
> hCard spec says that organizations and persons are distinguished there
> using the following rule:
>
> "If the "FN" and "ORG" properties have the exact same value (typically
> because they are set on the same element, e.g. class="fn org"), then the
> hCard represents contact information for a company, organization or
> place and SHOULD be treated as such. In this case the author also MUST
> NOT set the "N" property, or set it (and any sub-properties) explicitly
> to the empty string "". Thus parsers SHOULD handle the missing "N"
> property, in this case by implying empty values for all the "N"
> sub-properties. " See http://microformats.org/wiki/hcard
>
> Even if we don't formalize this constraint (AFAIK can not be done in
> OWL), at least we should explain that it helps to maximize compatibility
> if in the organization markup the value of fn and the value of
> organization-name is the same. We should also adapt the example
> accordingly, currently the vcard:fn is Example.Com, while the
> vcard:organization-name is Example.Com LLC .
>
> Thanks,
> Peter
>
>
>
> Renato Iannella wrote:
>> Ok guys - hopefully this is *really* it....please review:
>>
>> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091201.html
>> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>>
>> I've updated the Examples in Section 4 and 5 (rdfa new)....
>>
>> Comments/Feedback....
>>
>> Cheers... Renato Iannella
>> NICTA
>>
>>
>

Cheers... Renato Iannella
NICTA

Re: Final Final vCard (take 2)

2009-12-01T04:50:38Z

On Tue, 2009-12-01 at 15:50 +1000, Renato Iannella wrote:
> Ok guys - hopefully this is *really* it....please review:
>
> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091201.html
> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>
> I've updated the Examples in Section 4 and 5 (rdfa new)....
>
> Comments/Feedback....

You say "final final" but still ask for feedback! Will you never
learn?! ;-)

The RDF/XML snippets in the spec include a bunch of extra whitespace -
presumably for clarity. Whitespace is considered significant in RDF/XML,
so perhaps it's not a good idea to include it in the examples. Clarity
could be retained using a modicum of syntax highlighting - e.g. bolding
literals and resource URIs.

The e-mail address in the RDFa example would perhaps be nicer as:

<a rel="v:email" href="mailto:corky@...">corky@...</a>

This is likely to be closer to how it could be used in real life.

Also in the RDFa, I don't see much value in including the rdfs:Resource
types. Given that rdfs:Resource is essentially the base class of
everything (there is nothing which is not an rdfs:Resource), it doesn't
add any information and only serves to complicate the example.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

Re: Final Final vCard (take 2)

2009-12-01T02:53:38Z

Hi Renato,

Many thanks for this otherwise ungrateful work...

Here is a small suggestion to maximize compatibility with hCard. The
hCard spec says that organizations and persons are distinguished there
using the following rule:

"If the "FN" and "ORG" properties have the exact same value (typically
because they are set on the same element, e.g. class="fn org"), then the
hCard represents contact information for a company, organization or
place and SHOULD be treated as such. In this case the author also MUST
NOT set the "N" property, or set it (and any sub-properties) explicitly
to the empty string "". Thus parsers SHOULD handle the missing "N"
property, in this case by implying empty values for all the "N"
sub-properties. " See http://microformats.org/wiki/hcard

Even if we don't formalize this constraint (AFAIK can not be done in
OWL), at least we should explain that it helps to maximize compatibility
if in the organization markup the value of fn and the value of
organization-name is the same. We should also adapt the example
accordingly, currently the vcard:fn is Example.Com, while the
vcard:organization-name is Example.Com LLC .

Thanks,
Peter

Renato Iannella wrote:

> Ok guys - hopefully this is *really* it....please review:
>
> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091201.html
> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>
> I've updated the Examples in Section 4 and 5 (rdfa new)....
>
> Comments/Feedback....
>
> Cheers... Renato Iannella
> NICTA
>
>

Re: Final Final vCard (take 2)

2009-12-01T01:26:07Z

Hello Renato, thanks for prompt updates.

HTML spec page looks good, but schema RDF still has conflicting descriptions.

[[[
<!ENTITY vcard "http://www.w3.org/2006/vcard/" >
...
<owl:ObjectProperty rdf:about="&vcard;adr">
etc...
]]]

With &vcard;, the expanded URI for the property is
http://www.w3.org/2006/vcard/adr . Instead, you should use &ns; which
you declared as:

[[[
<!ENTITY ns "http://www.w3.org/2006/vcard/ns#" >
]]]

cheers,

--
@prefix : <http://www.kanzaki.com/ns/sig#> . <> :from [:name
"KANZAKI Masahide"; :nick "masaka"; :email "mkanzaki@..."].

Final Final vCard (take 2)

2009-11-30T21:50:30Z

Ok guys - hopefully this is *really* it....please review:

http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091201.html
http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf

I've updated the Examples in Section 4 and 5 (rdfa new)....

Comments/Feedback....

Cheers... Renato Iannella
NICTA

Re: Final Final vCard

2009-11-30T19:28:23Z

On 1 Dec 2009, at 01:35, Peter Mika wrote:

> It would be also great if you could give an example of how to mark up an
> organization. Namely, both Google and us are using VCard for business
> listings. That's also where the pain is...

I will add one to the Example section...please see next version.....

Cheers... Renato Iannella
NICTA

Re: Final Final vCard

2009-11-30T11:46:18Z

On 30 Nov 2009, at 17:51, Doug Schepers wrote:

>>Not essential, but it would be interesting (and maybe helpful to 
>>authors) to have an informative example using RDFa.


>Good idea Doug - we could convert the example in Section 4?

>Any takers?

If you have RDF/XML examples, you can turn them into RDFa with

http://www.ebusiness-unibw.org/tools/rdf2rdfa/

If you prefer to use the same literals for the browser and RDFa agents, you can simply edit the snippets returned by RDF2RDFa.

Martin

--

------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  hepp@...
phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================

Project page:
http://purl.org/goodrelations/

Resources for developers:
http://www.ebusiness-unibw.org/wiki/GoodRelations

Webcasts:
Overview - http://www.heppnetz.de/projects/goodrelations/webcast/
How-to   - http://vimeo.com/7583816

Recipe for Yahoo SearchMonkey:
http://www.ebusiness-unibw.org/wiki/GoodRelations_and_Yahoo_SearchMonkey

Talk at the Semantic Technology Conference 2009: 
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://www.slideshare.net/mhepp/semantic-webbased-ecommerce-the-goodrelations-ontology-1535287

Overview article on Semantic Universe:
http://www.semanticuniverse.com/articles-semantic-web-based-e-commerce-webmasters-get-ready.html

Tutorial materials:
ISWC 2009 Tutorial: The Web of Data for E-Commerce in Brief: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey 
http://www.ebusiness-unibw.org/wiki/Web_of_Data_for_E-Commerce_Tutorial_ISWC2009

Re: Final Final vCard

2009-11-30T11:43:50Z

Hi Peter,
This was more a comment re Yahoo's and Google's honoring of structured
data ;-) But a reference to GoodRelations in the vcard spec may be
valuable for motivating broad audiences to produce rich company and
product descriptions.

Something along the lines of "For more comprehensive descriptions of a
business, its stores, or products, please consider the GoodRelations
ontology, http://purl.org/goodrelations/."

Martin

Peter Mika wrote:

> Hi Martin,
>
> This is about the VCard spec, and although I understand there is a
> relationship to GoodRelations, that's probably not necessary to
> document in the spec (IMHO).
>
> Peter
>
> Martin Hepp (UniBW) wrote:
>> Hi Peter,
>> what about using gr:BusinessEntity for the business and
>> gr:LocationOfSalesOrServiceProvisioning for the stores? You can then
>> attach contact details with vcard to that node?
>>
>> gr : <http://purl.org/goodrelations/v1#>
>>
>> Martin
>>
>>
>>
>> Martin
>>
>> Peter Mika wrote:
>>
>>> Hi Renato,
>>>
>>> It would be also great if you could give an example of how to mark
>>> up an organization. Namely, both Google and us are using VCard for
>>> business listings. That's also where the pain is...
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>> Renato Iannella wrote:
>>>
>>>> Ok guys - hopefully this is it....please review:
>>>>
>>>> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
>>>> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>>>>
>>>> Appendix A should now reflect the schema, and includes the unions
>>>> and restrictions.
>>>>
>>>> I've also added the WGS restrictions for the Location class.
>>>>
>>>> Comments/Feedback....
>>>>
>>>> I would *really* like to submit to W3C this week....
>>>>
>>>> Cheers... Renato Iannella
>>>> NICTA
>>>>
>>>>
>>>
>>
>>
>
>

--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail: hepp@...
phone: +49-(0)89-6004-4217
fax: +49-(0)89-6004-4620
www: http://www.unibw.de/ebusiness/ (group)
http://www.heppnetz.de/ (personal)
skype: mfhepp
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================

Project page:
http://purl.org/goodrelations/

Resources for developers:
http://www.ebusiness-unibw.org/wiki/GoodRelations

Webcasts:
Overview - http://www.heppnetz.de/projects/goodrelations/webcast/
How-to - http://vimeo.com/7583816

Recipe for Yahoo SearchMonkey:
http://www.ebusiness-unibw.org/wiki/GoodRelations_and_Yahoo_SearchMonkey

Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://www.slideshare.net/mhepp/semantic-webbased-ecommerce-the-goodrelations-ontology-1535287

Overview article on Semantic Universe:
http://www.semanticuniverse.com/articles-semantic-web-based-e-commerce-webmasters-get-ready.html

Tutorial materials:
ISWC 2009 Tutorial: The Web of Data for E-Commerce in Brief: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey
http://www.ebusiness-unibw.org/wiki/Web_of_Data_for_E-Commerce_Tutorial_ISWC2009

Re: Final Final vCard

2009-11-30T09:00:27Z

Peter, Renato,

Maybe http://sw-app.org/mic.xhtml can be of help ...

Cheers,
Michael

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

> From: Peter Mika <pmika@...>
> Date: Mon, 30 Nov 2009 17:57:23 +0100
> To: "martin.hepp@..." <martin.hepp@...>
> Cc: Renato Iannella <renato@...>, Norman Walsh <ndw@...>,
> Brian Suda <brian.suda@...>, Harry Halpin <hhalpin@...>, Toby A
> Inkster <tai@...>, Dan Brickley <danbri@...>,
> "www-archive@..." <www-archive@...>
> Subject: Re: Final Final vCard
> Resent-From: <www-archive@...>
> Resent-Date: Mon, 30 Nov 2009 16:58:29 +0000
>
> Hi Martin,
>
> This is about the VCard spec, and although I understand there is a
> relationship to GoodRelations, that's probably not necessary to document
> in the spec (IMHO).
>
> Peter
>
> Martin Hepp (UniBW) wrote:
>> Hi Peter,
>> what about using gr:BusinessEntity for the business and
>> gr:LocationOfSalesOrServiceProvisioning for the stores? You can then
>> attach contact details with vcard to that node?
>>
>> gr : <http://purl.org/goodrelations/v1#>
>>
>> Martin
>>
>>
>>
>> Martin
>>
>> Peter Mika wrote:
>>
>>> Hi Renato,
>>>
>>> It would be also great if you could give an example of how to mark up
>>> an organization. Namely, both Google and us are using VCard for
>>> business listings. That's also where the pain is...
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>> Renato Iannella wrote:
>>>
>>>> Ok guys - hopefully this is it....please review:
>>>>
>>>> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
>>>> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>>>>
>>>> Appendix A should now reflect the schema, and includes the unions and
>>>> restrictions.
>>>>
>>>> I've also added the WGS restrictions for the Location class.
>>>>
>>>> Comments/Feedback....
>>>>
>>>> I would *really* like to submit to W3C this week....
>>>>
>>>> Cheers... Renato Iannella
>>>> NICTA
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

Re: Final Final vCard

2009-11-30T08:57:23Z

Hi Martin,

This is about the VCard spec, and although I understand there is a
relationship to GoodRelations, that's probably not necessary to document
in the spec (IMHO).

Peter

Martin Hepp (UniBW) wrote:

> Hi Peter,
> what about using gr:BusinessEntity for the business and
> gr:LocationOfSalesOrServiceProvisioning for the stores? You can then
> attach contact details with vcard to that node?
>
> gr : <http://purl.org/goodrelations/v1#>
>
> Martin
>
>
>
> Martin
>
> Peter Mika wrote:
>
>> Hi Renato,
>>
>> It would be also great if you could give an example of how to mark up
>> an organization. Namely, both Google and us are using VCard for
>> business listings. That's also where the pain is...
>>
>> Thanks,
>> Peter
>>
>>
>> Renato Iannella wrote:
>>
>>> Ok guys - hopefully this is it....please review:
>>>
>>> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
>>> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>>>
>>> Appendix A should now reflect the schema, and includes the unions and
>>> restrictions.
>>>
>>> I've also added the WGS restrictions for the Location class.
>>>
>>> Comments/Feedback....
>>>
>>> I would *really* like to submit to W3C this week....
>>>
>>> Cheers... Renato Iannella
>>> NICTA
>>>
>>>
>>>
>>
>
>

Re: Final Final vCard

2009-11-30T08:32:50Z

Hi Peter,
what about using gr:BusinessEntity for the business and
gr:LocationOfSalesOrServiceProvisioning for the stores? You can then
attach contact details with vcard to that node?

gr : <http://purl.org/goodrelations/v1#>

Martin

Martin

Peter Mika wrote:

> Hi Renato,
>
> It would be also great if you could give an example of how to mark up
> an organization. Namely, both Google and us are using VCard for
> business listings. That's also where the pain is...
>
> Thanks,
> Peter
>
>
> Renato Iannella wrote:
>> Ok guys - hopefully this is it....please review:
>>
>> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
>> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>>
>> Appendix A should now reflect the schema, and includes the unions and
>> restrictions.
>>
>> I've also added the WGS restrictions for the Location class.
>>
>> Comments/Feedback....
>>
>> I would *really* like to submit to W3C this week....
>>
>> Cheers... Renato Iannella
>> NICTA
>>
>>
>
>

Re: Final Final vCard

2009-11-30T07:35:52Z

Hi Renato,

It would be also great if you could give an example of how to mark up an
organization. Namely, both Google and us are using VCard for business
listings. That's also where the pain is...

Thanks,
Peter

Renato Iannella wrote:

> Ok guys - hopefully this is it....please review:
>
> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>
> Appendix A should now reflect the schema, and includes the unions and restrictions.
>
> I've also added the WGS restrictions for the Location class.
>
> Comments/Feedback....
>
> I would *really* like to submit to W3C this week....
>
> Cheers... Renato Iannella
> NICTA
>
>

Re: Final Final vCard

2009-11-30T04:19:02Z

On 30 Nov 2009, at 18:44, KANZAKI Masahide wrote:

> Maybe they should be "http://www.w3.org/2006/vcard/ns#Address" etc for
> the compatibility with current RDF VCard ?

Thanks for picking that up!

Cheers... Renato Iannella
NICTA

Re: Final Final vCard

2009-11-30T04:11:59Z

On 30 Nov 2009, at 17:51, Doug Schepers wrote:

> Not essential, but it would be interesting (and maybe helpful to
> authors) to have an informative example using RDFa.

Good idea Doug - we could convert the example in Section 4?

Any takers?

Cheers... Renato Iannella
NICTA

Re: Final Final vCard

2009-11-30T00:44:45Z

Hello Renato,

I've not been following discussion closely, but it seems contradiction
to state that
[[[
For vCard, the following URI is defined to be the RDF vCard Namespace:
http://www.w3.org/2006/vcard/ns#
]]]

while describing all Classes and Properties as
"http://www.w3.org/2006/vcard/Address" etc. in the schema/ontology.

Maybe they should be "http://www.w3.org/2006/vcard/ns#Address" etc for
the compatibility with current RDF VCard ?

cheers,

--
@prefix : <http://www.kanzaki.com/ns/sig#> . <> :from [:name
"KANZAKI Masahide"; :nick "masaka"; :email "mkanzaki@..."].

Re: Final Final vCard

2009-11-29T23:51:18Z

Hi, Renato-

Renato Iannella wrote (on 11/30/09 12:45 AM):

>
> Ok guys - hopefully this is it....please review:
>
> http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
> http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf
>
> Appendix A should now reflect the schema, and includes the unions and restrictions.
>
> I've also added the WGS restrictions for the Location class.
>
> Comments/Feedback....
>
> I would *really* like to submit to W3C this week....

Not essential, but it would be interesting (and maybe helpful to
authors) to have an informative example using RDFa.

(Sorry if this has already been discussed, I haven't been following the
thread.)

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Final Final vCard

2009-11-29T21:45:14Z

Ok guys - hopefully this is it....please review:

http://spin.nicta.org.au/vCardRDF/vcard-rdf-20091130.html
http://spin.nicta.org.au/vCardRDF/ns2009-final.rdf

Appendix A should now reflect the schema, and includes the unions and restrictions.

I've also added the WGS restrictions for the Location class.

Comments/Feedback....

I would *really* like to submit to W3C this week....

Cheers... Renato Iannella
NICTA

Re: Proposed W3C Spec Conventions

2009-11-27T00:29:23Z

Hi, Simon-

Thanks for the comments, replies inline...

Simon Pieters wrote (on 11/27/09 2:42 AM):
> On Fri, 27 Nov 2009 00:47:42 +0100, Doug Schepers <schepers@...> wrote:
>>
>> * semantic tags such as , , <dfn>, <var>, <code>, etc.
>> wherever possible, rather than or <div>
>
> I think inline notes, warnings and examples etc should use rather
> than ; the label is enough to notify the reader that it's different
> from the surrounding prose, and you might want to use emphasis inside.

That was my original approach, and how I currently do this in DOM3
Events, but upon reading Gregory's comments, I thought it would be
better for accessibility to use . It does make sense to do so,
since the passages are being emphasized, but I could go either way. I'd
like to hear what people who read specs using a screen-reader say.

>> * named colors rather than numerical color codes
>> * prefaced notes, issues, and other categories with prose labels in
>> the document, rather than relying on text inserted by CSS; CSS
>> insertions are now used only for emphasis symbols
>
> I presume editors will not fancy writing the labels by hand, so a tool
> like Anolis will probably be used to insert them. Is there a reason why
> inline examples don't have the label "Example: "?

I looked over a few specs, and that doesn't currently seem to be what's
done in practice (usually specs say "For example," or "As an example,"),
and "Example:" strikes me as particularly stilted. I don't feel too
strongly about it, though, and if others agree with you, I'm fine with
adopting that.

> Isn't To Do redundant with Issue?

To Do is a little more specific than issue. Issue implies a problem of
some sort, while To Do indicates that the editor wants the reader to
know that something needs to go in that section, but hasn't gotten
around to it yet. For example, an editor might use To Do as a
placeholder for a diagram or example that clarifies the existing prose,
or for an empty section that just has a heading.

> Is it intended that they use the same class name?

Yes, that's why it's a subcategory of Issue.

> Regarding id=""s, here I'll also assume that a tool like Anolis will
> generate id=""s. However, I don't see any reason to id=""ify all content
> that is covered by a category, as the document suggests; for instance I
> wouldn't put an id="" on <var>s or xrefs.

An @id on a <var> seems useful (though not always), but I agree about
cross-references... I didn't mean to imply that.

>If every gets an
> auto-generated id="", then they're very likely to change as the spec is
> being edited, which makes them not so useful to link to anyway.

I'm not sure where you got the idea that I recommend every gets an
id. I'll try to clarify that.

>Having
> id=""s on headings and definitions goes a long way. Notes, warnings,
> issues and examples are reasonable candidates.

Yes, these are the most important ones.

> Personally I'd prefer <dfn>s non-italic and bold (possibly <dt><dfn>
> italic and bold), and xrefs as non-italic link-looking.

Okay, I'll keep a straw poll running on this bikeshed. I'm not married
to the current style of any of this, and I hope we can get a designer to
make it look like it wasn't designed by a geek (which, surprise!, it
was). Italics can be annoying for term references, I agree, but I would
like something to set them apart from normal links.

> The Markup terms (should be called something else since <code> isn't
> just used for markup)

Suggestions? (Note that I'm not saying <code> is only used for marking
up markup... just that markup should use that.)

> has classes for elements and properties, but this
> doesn't cover the various kinds of concepts that specs would like to use
> <code> for.

This document is not trying to solve every case, just the major ones;
too many rules, and it will be too complicated to get adopted. If you
provide a list of things you think are missing, I'll consider those, too.

> I'd suggest having lone <code> for elements, properties, and
> everything else that doesn't have a fancy style,

I definitely want to distinguish between element names, and attributes
and properties names.

>and <code class="value"> and <code class="string">
> for the blueish background.

I'm drawing a blank where class="string" would be used... can you clarify?

> <var> is misplaced and has the wrong style since variables aren't
> necessarily code. For example, it's common for algorithms to use variables.

It's under "Code and Related Technical Terms"... a variable in an
algorithm is still a technical term. However, if you can think of a
better heading, I'll consider that.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: Proposed W3C Spec Conventions

2009-11-26T23:42:52Z

On Fri, 27 Nov 2009 00:47:42 +0100, Doug Schepers <schepers@...> wrote:

> Hi, Gregory-
>
> You expressed interest and provided feedback on Karl's typographic
> conventions for specifications several months ago. We have picked up
> that effort again, and I've tried to integrate all the feedback gathered
> at that time.
>
> In response to your comments, I've made the following changes:
>
> * semantic tags such as , , <dfn>, <var>, <code>, etc.
> wherever possible, rather than or <div>

I think inline notes, warnings and examples etc should use rather
than ; the label is enough to notify the reader that it's different
from the surrounding prose, and you might want to use emphasis inside.

> * named colors rather than numerical color codes
> * prefaced notes, issues, and other categories with prose labels in the
> document, rather than relying on text inserted by CSS; CSS insertions
> are now used only for emphasis symbols

I presume editors will not fancy writing the labels by hand, so a tool
like Anolis will probably be used to insert them. Is there a reason why
inline examples don't have the label "Example: "?

Isn't To Do redundant with Issue? Is it intended that they use the same
class name?

Regarding id=""s, here I'll also assume that a tool like Anolis will
generate id=""s. However, I don't see any reason to id=""ify all content
that is covered by a category, as the document suggests; for instance I
wouldn't put an id="" on <var>s or xrefs. If every gets an
auto-generated id="", then they're very likely to change as the spec is
being edited, which makes them not so useful to link to anyway. Having
id=""s on headings and definitions goes a long way. Notes, warnings,
issues and examples are reasonable candidates.

Personally I'd prefer <dfn>s non-italic and bold (possibly <dt><dfn>
italic and bold), and xrefs as non-italic link-looking.

The Markup terms (should be called something else since <code> isn't just
used for markup) has classes for elements and properties, but this doesn't
cover the various kinds of concepts that specs would like to use <code>
for. I'd suggest having lone <code> for elements, properties, and
everything else that doesn't have a fancy style, and <code class="value">
and <code class="string"> for the blueish background.

<var> is misplaced and has the wrong style since variables aren't
necessarily code. For example, it's common for algorithms to use variables.

> If you would review the most recent draft of the documentation [1] and
> the stylesheet [2] for accessibility concerns, I would appreciate it.
>
> [1] http://www.w3.org/People/Schepers/spec-conventions.html
> [2] http://www.w3.org/StyleSheets/TR/w3c-tr.css
>

--
Simon Pieters
Opera Software

Re: Proposed W3C Spec Conventions

2009-11-26T15:47:42Z

Hi, Gregory-

You expressed interest and provided feedback on Karl's typographic
conventions for specifications several months ago. We have picked up
that effort again, and I've tried to integrate all the feedback gathered
at that time.

In response to your comments, I've made the following changes:

* semantic tags such as , , <dfn>, <var>, <code>, etc.
wherever possible, rather than or <div>
* named colors rather than numerical color codes
* prefaced notes, issues, and other categories with prose labels in the
document, rather than relying on text inserted by CSS; CSS insertions
are now used only for emphasis symbols

If you would review the most recent draft of the documentation [1] and
the stylesheet [2] for accessibility concerns, I would appreciate it.

[1] http://www.w3.org/People/Schepers/spec-conventions.html
[2] http://www.w3.org/StyleSheets/TR/w3c-tr.css

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Doug Schepers wrote (on 11/23/09 3:44 AM):

[wbs] response to 'Grant II: Grant of License for Contributed Test Cases Published Outside a W3C Recommendation'

2009-11-26T14:02:01Z

The following answers have been successfully submitted to 'Grant II: Grant
of License for Contributed Test Cases Published Outside a W3C
Recommendation' (public) for by .

---------------------------------
Information about the Contributor
----
Please provide the required information about the contributor.

Name of the contributing organization (or your name if contributed by an
individual): Gérard Talbot
Your role in that organization (leave blank if contributed by an
individual):

---------------------------------
Information about the Contribution
----
Please provide sufficient information to identify the contributed test
cases (e.g., a URI or other reference).

Comments (or a URI pointing to your comments):
All the tests appearing in

http://test.csswg.org/source/contributors/gtalbot/

and/or

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

---------------------------------
Additional Relevant Information
----
Please provide any other information that is relevant to the contribution.

Some tests submitted have also a credit <link> to additional web
authors as relevant contributors to tests I submitted, in particular:

James Hopkins: james(a)idreamincode.co.uk (17 tests so far)

Alexander Dawson: alexander_dawson(a)hotmail.com (1 test on universal
selector)

Mark McKenzie-Bell: info(a)temerity.co.uk (1 test on universal selector)

Justin Boss: http://www.bosspro.org/contactus/ (1 test on white-space)

Vasil Dinkov: http://www.vadikom.com/ (1 test on clip)

Some other tests do not have the original people's contact info and could
not be reached (so far), so I could not ask them to fill in the form to get
credited:

"mvdleij": http://magicm.awardspace.com/ie/

and

Daniel "the_dees" Schattenkirchner:
http://www.freewebs.com/the-dees/ie9/bug006.html
http://www.freewebs.com/the-dees/ie9/bug008.html
etc.

and

Sven Groot:
http://www.ookii.org/misc/ie8/overflow_scroll_max_height_bug.html

---------------------------------
Confirmation of Agreement
----
Once you have provided the information required above, please
confirm the following statement and then submit the form to complete
your contribution.

* [x] On behalf of the contributing organization named above, I agree to
the above Grant of License for Contributed Test Cases Published Outside a
W3C Recommendation.

These answers were last modified on
by

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/1/testgrants2-200409/ until 2010-10-01.

Regards,

The Automatic WBS Mailer

Re: Proposed W3C Spec Conventions

2009-11-26T04:04:30Z

Hi Doug,

About the [W3C Spec Conventions][4]

Le 26 nov. 2009 à 01:32, Doug Schepers a écrit :
> Karl Dubost wrote (on 11/25/09 7:35 AM):
>> Very good to see this pushed forward.
>> I would show it to a few selected Web designers to have an opinion about colors.
>
> Great idea. Any suggestions for designers?

Jon Hicks [Hicksdesign][1] is [working][2] for Opera now.
Maybe he is willing to give a hand.
To [contact][3] him

[1]: http://hicksdesign.co.uk/
[2]: http://hicksdesign.co.uk/journal/and-now-opera
[3]: http://hicksdesign.co.uk/contact
[4]: http://www.w3.org/People/Schepers/spec-conventions.html

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/

Re: Proposed W3C Spec Conventions

2009-11-25T22:32:12Z

Hi, Karl-

Karl Dubost wrote (on 11/25/09 7:35 AM):
> Hi Doug,
>
> Le 25 nov. 2009 à 02:41, Doug Schepers a écrit :
>> I've incorporated it, and created a new draft:
>> http://www.w3.org/People/Schepers/spec-conventions.html
>
> Very good to see this pushed forward.
> I would show it to a few selected Web designers to have an opinion about colors.

Great idea. Any suggestions for designers?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Re: Proposed W3C Spec Conventions

2009-11-25T22:30:07Z

Hi, fantasai-

fantasai wrote (on 11/25/09 5:05 PM):

>
> Right, so like I said
>
>> > Maybe you're complaining about things like
>> > <code><pre>...</pre></code>
>> > not working? That would be because the markup is invalid.
>
> It's still invalid.
>
> Maybe this will get this point across:

Oops. I misparsed what you had said there. I often screw that up, the
content model for <code> and <pre> seem a bit arbitrary to me. Fixed now.

> For defining instance of term, I prefer a convention that uses
> <dt><dfn>term</dfn></dt>
> instead of
> <dt>term</dt>
> as I sometimes use the latter for things that shouldn't get marked up in
> the index as defining instances of a term.
>
> Note HTML5's explanation here:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-dt-element
>
> specifically
> "The dt element itself, when used in a dl element, does not indicate
> that its contents
> are a term being defined, but this can be indicated using the dfn element."

Huh, I'd never made that distinction before. I only use <dt> for
glossaries, but I'll start using <dfn> as well, now. Fixed.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs