Re: [whatwg] [web-apps] 2.7.8 The i element

[fantasai]

Anne van Kesteren wrote:
Ian Hickson wrote:
Then would you want different markup for book titles, movie titles,
play titles, song titles, etc?  Or would you just expect the script
to search IMDB for anything marked up with ?
Again, I don't really know. I could see a use case for a "type"
attribute (as was suggested earlier in this thread), but that seems
like a slippery slope. Suggestions?
If we go with something like a TYPE attribute, I hope we can give it a
better name. However, hiding semantics inside the value of an attribute 
is a poor markup design in humble opinion. (Although it also has some 
advantages.)
It's subclassing: the general is sufficient, the specific better. Many
markup languages use the design, and in this case, I think it's necessary.
~fantasai

Re: [whatwg] [WA1] lang and xml:lang

[Ian Hickson]

On Sun, 17 Apr 2005, Anne van Kesteren wrote:
> >
> > [xml:lang]
> 
> I assume we are going to do something similar for 'xml:id' when that 
> becomes REC? Or do the issues with regard to type ID need to be sorted 
> out first?

Actually, I just took out the text about xml:id. I couldn't work out why 
we'd want people to use xml:id rather than ID.

For xml:lang it makes sense, because there are systems that will want to 
crawl XML documents and find stuff in certain languages, and "lang" is not 
used often so making it longer is not a huge deal. But the ID of an 
element is a meaningless string, so the benefits of making non-HTML UAs be 
able to determine an HTML element's ID doesn't seem to outweigh the 
problems (four extra characters very time "id" is used, which is a lot, 
not to mention the namespace confusion).

Also, xml:lang="" and lang="" clash. An element can't have more than one 
language. However, xml:id="" and id="" can coexist without any trouble.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WA1] lang and xml:lang

[Anne van Kesteren]

Ian Hickson wrote:
Is there any reason for not making that "must not"?  The only
reason someone would ever have for using lang instead of xml:lang
in XHTML is when serving it as text/html, which is strictly
forbidden in this version.  It should be stated that lang is for
HTML only and xml:lang is for X(HT)ML only.
Done.

I think the heading for the attribute defintion should be updated
to include xml:lang as well.
Done.
I assume we are going to do something similar for 'xml:id' when that 
becomes REC? Or do the issues with regard to type ID need to be sorted 
out first?

--
 Anne van Kesteren
 

Re: [whatwg] WA1 dl and dialog

[Anne van Kesteren]

fantasai wrote:
I like the definition you give here, except for one thing:
Despite the example given in HTML4, I think that speakers and words
is stretching the name-value idea a bit too far. For scripted dialog,
I think Tantek's suggestion is much better:
  http://tantek.com/presentations/2005/03/elementsofxhtml/#slide20
It also requires a lot of additional markup. Can't we just say that when 
you want to give additional semantics, like you need to use DFN for real 
definitions, you need to use {Person} and either 
{Quote} or ...{Quote}


So my suggestion is to remove that particular example from the spec.
I think it should be kept. But that there should be a similar note like 
the one about DFN.

--
 Anne van Kesteren
 

Re: [whatwg] [web-apps] 2.7.8 The i element

[Anne van Kesteren]

Ian Hickson wrote:
That's the problem. Would abusing  for this be acceptable? Do we 
need another element?
I think that would be acceptable. Although I wonder if CITE would still 
be the right name... Can you still use CITE for persons in that case?

 John E. Simpson said in XPath and
  XPointer: ...

I don't particularly plan on ever linking to a urn:, since the likelihood 
of their being successfully dereferenced is extremely low. I don't think 
that's really a workable solution.
It is also not really backwards compatible. (However, you already linked 
to a URN once using the CITE attribute on a BLOCKQUOTE...)


yet there is something very different about that one -- it's the title 
of another work. I'd like to be able to style all such titles 
consistently, so they have to be marked up in some way.
In that case, would you want to differentiate between ordinary titles 
and real citations?  Or is that something that the class attribute could 
handle, if needed?
I don't know. What do people think?
See above.

Movie titles are similar. I'd like my UA to give me a tooltip 
containing information from IMDB for every movie title. With user
 JavaScript I can do this, if there's a way to recognise movie
titles.
Then would you want different markup for book titles, movie titles,
play titles, song titles, etc?  Or would you just expect the script
to search IMDB for anything marked up with ?
Again, I don't really know. I could see a use case for a "type"
attribute (as was suggested earlier in this thread), but that seems
like a slippery slope. Suggestions?
If we go with something like a TYPE attribute, I hope we can give it a
better name. However, hiding semantics inside the value of an attribute 
is a poor markup design in humble opinion. (Although it also has some 
advantages.)

--
 Anne van Kesteren
 

Re: [whatwg] [web-apps] 2.7.8 The i element

[Anne van Kesteren]

Ian Hickson wrote:
Is there any advantage to marking up people's names?
Not really. As there is no way to distinquish two people sharing the
same name. Furthermore, it would only be useful for the few who "love
semantics", since names are typically not rendered any different from
other paragraph text.

Maybe we should just let ship names be marked up by  (it is, after
all, an instance of use of a term, as it were), and say that  
can be used for any reference to a publication, including those that 
aren't really citations ("my favourite book is ...").
We need italics for other things as well:
# Looking over the index entry for "Italics" in my Chicago Manual of
# Style, I see that italics can be used for emphasis, foreign words,
# genus and species, key terms, legal cases, letters as letters and
# words as words, letters in enumeration, math, questions (as
# quotatives), rhyme schemes, ship names, stage directions, subheads,
# technical terms, theorems, and titles (of books, journals, movies,
# musical works, paintings, plays, and poems). Among other things. A
# lot of these are just typographical conventions in English that do
# not pertain in all other languages. I think this is exactly what the
# i tag was invented for.

--
 Anne van Kesteren
 

Re: [whatwg] [WA1] The profile Attribute

[Ian Hickson]

On Sun, 17 Apr 2005, James Graham wrote:
> > > > 
> > > > The only way I can see to avoid this is to use only one profile, 
> > > > since then you can't ever get clashes.
> > > 
> > > There are other ways I've seen proposed, such as using namespaces:
> > > 
> > > http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm
> > 
> > Namespaces are not an option. Authors simply don't understand them.
> 
> Respectfully, I think namespaces are the only sensible solution here and in
> other situations where the document is mixing semantics from multiple sources.

The recent microformats trend (using profile="") is one other solution, 
which seems to be at least as sensible.


> What's the evidence that authors don't understand namespaces?

One source for example is Micah Dubinko's statistic that 90% of all the 
queries about XForms that he receives are asking for him to explain 
namespaces. [1]

  [1] http://www.w3.org/2004/04/webapps-cdf-ws/papers/verity.html

This certainly has also been my experience in dealing with Web authors who 
are trying to use languages that rely on namespaces.


> Does it all come from XML namespaces (which are more complex than 
> anything we would need for this type of problem*)? In any case I think 
> this is a situation where, with sensible defaults, we can provide a 
> useful feature that will be well within the grasp of the small subset of 
> authors who actually want to use it.

By "namespaces" here I am refering to XML namespaces and similar solutions 
that require declaring a prefix and then using that prefix elsewhere.


> For example we could define  href="http://example.com/profiles/#foo"; /> and then require a profile 
> attribute for elements with rel values not assosiated with the default 
> profile, which would be given by the value of the profile attribute in 
>  or the last  element with no  value. That seems 
> much simpler than XML namespaces.

That seems a lot more complicated than the current proposed solution with 
profile="".

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WA1] lang and xml:lang

[Ian Hickson]

On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> > > 
> > > # If both the xml:lang attribute and the lang attribute are set, user
> > > # agents must use the xml:lang attribute, and the lang attribute must be
> > > # ignored for the purposes of determining the element's language.
> > > 
> > > Is that the case for both HTML and XHTML documents?
> > 
> > Yes.
> 
> So, if I have this HTML document
> 
>   
>   
>   HTML document
>   This is an HTML, not an XML, document.
> 
> Considering that legacy HTML UAs won't know about the xml:lang 
> attribute, and will only use lang, are you saying that a conforming Web 
> Apps UA should treat the document as french?

No. The "xml:lang" attribute in that document is not the xml:lang 
attribute. It's the {null, "xml:lang"} attribute -- the attribute in the 
null namespace with the local name "xml:lang" -- whereas the xml:lang 
attribute, the one defined by XML, is the {xml, "lang"} attribute: the 
attribute in the XML namespace with the local name "lang".

See Namespaces in XML for more information.



> > > It would make more sense if, in the case of both being set, lang was 
> > > used for text/html documents and xml:lang for XML documents.
> > 
> > The only way you can set xml:lang in an HTML document is via the DOM
> 
> Now I'm confused.  If that's the case, then wouldn't the above example 
> be treated as english [...]

Yes.


> > (in HTML, there are no namespaces).
> 
> Which is why xml:lang should be completely ignored, as an unknown 
> attribute, in HTML.

If there is a literal "xml:lang" attribute in an HTML document, it is 
ignored and has no effect on this conformance requirement. That, however, 
is not an xml:lang attribute.

Since this is clearly a source of confusion, I've added a paragraph to the 
Terminology section about this.


> I've seen people use lots of XML syntax in HTML documents, including 
> xmlns and xml:lang attributes even in one that had an explicit HTML4 
> DOCTYPE (though I can't remember where) and not just in MS Word 
> generated rubbish.  The point is authors do a lot of silly things, and I 
> thought UA behaviour needed to be well defined for as many use cases as 
> possible.

Absolutely. However none of the cases you mentioned result in the 
existence of a "lang" attribute in the XML namespace. They result in 
unknown attributes in the null namespace, which is very different.


> > > However, in the case of only one being set but for the wrong MIME 
> > > type (eg. xml:lang set for text/html document or lang for XML 
> > > document), for error recovery, should UAs be allowed to fallback on 
> > > it?
> > 
> > If xml:lang="" is set onin a text/html document, it'll be {html, 
> > 'xml:lang'}, not {xml, 'lang'} which is what xml:lang really is.

(Er, I should have said {null, 'xml:lang'}, not {html, 'xml:lang'}.)

> I don't understand how that answers the question.

I hope this e-mail clarifies it for you.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WA1] The profile Attribute

[James Graham]

Ian Hickson wrote:
On Sun, 17 Apr 2005, Lachlan Hunt wrote:
Imagine you use publicly available profiles A and B.
Two months later, the author of profile A updates his profile to 
include the definition "baz", meaning something completely different 
to the definition from profile B.
Well, I'd say the author of profile A has broken some rules by not 
keeping the URI for an old version persistent.

There is no way we are requiring a new URI every time the profile changes. 
That would be an administrative nightmare for editors, authors, and UA 
implementors. It would make working out common semantics nigh on 
impossible. IMHO, anyway.


The only way I can see to avoid this is to use only one profile, since 
then you can't ever get clashes.
There are other ways I've seen proposed, such as using namespaces:
http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm

Namespaces are not an option. Authors simply don't understand them.
Respectfully, I think namespaces are the only sensible solution here and 
in other situations where the document is mixing semantics from multiple 
sources. What's the evidence that authors don't understand namespaces? 
Does it all come from XML namespaces (which are more complex than 
anything we would need for this type of problem*)? In any case I think 
this is a situation where, with sensible defaults, we can provide a 
useful feature that will be well within the grasp of the small subset of 
authors who actually want to use it.

* For example we could define http://example.com/profiles/#foo"; /> and then require a profile 
attribute for elements with rel values not assosiated with the default 
profile, which would be given by the value of the profile attribute in 
 or the last  element with no  value. That seems 
much simpler than XML namespaces.

--
"Sir: "Offence" is not confined to the religious. I take offence at 
"Rudolph the Red-Nosed Reindeer", "Jingle Bells" and all that they stand 
for; at ten-gallon hats and other symbols of American aggression; at 
slit-eyed black veils and other symbols of the oppression of women; at 
First Communion veils, and other symbols of the indoctrination of 
children. But I do not start a riot when I encounter them, nor try to 
get them banned by law. I mutter through gritted teeth and turn the 
other way.

There is a case to be made that all of us should try to avoid giving 
gratuitous offence to others. But how has our secular society been 
conned into allowing religious offence to jump the queue and claim 
special privileges?"

- Richard Dawkins (The Independent, 24th December 2004)

Re: [whatwg] [WA1] The profile Attribute

[Ian Hickson]

On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> > 
> > Imagine you use publicly available profiles A and B.
> > 
> > Two months later, the author of profile A updates his profile to 
> > include the definition "baz", meaning something completely different 
> > to the definition from profile B.
> 
> Well, I'd say the author of profile A has broken some rules by not 
> keeping the URI for an old version persistent.

There is no way we are requiring a new URI every time the profile changes. 
That would be an administrative nightmare for editors, authors, and UA 
implementors. It would make working out common semantics nigh on 
impossible. IMHO, anyway.


> > The only way I can see to avoid this is to use only one profile, since 
> > then you can't ever get clashes.
> 
> There are other ways I've seen proposed, such as using namespaces:
> 
> http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm

Namespaces are not an option. Authors simply don't understand them.


> Although that proposal doesn't seem to even make use of the profile 
> attribute, but rather link elements which would be a big improvment over 
> the profile attribute.

I don't really understand that.


> > Imagine you use publicly available profiles A and B.
> > 
> > A has definitions "foo" and "bar".
> > B has definitions "foo" and "baz".
> > 
> > Someone uses a browser that supports only profile B. Now your document 
> > will be rendered or processed with completely different semantics, 
> > because the UA thinks that by "foo" you mean B's "foo".
> 
> That's a valid use case to avoid profiles with conflicting definitions, 
> not against multiple profiles in general.

That sounds nice in theory but in practice it's not really something you 
can control. Even when one group of people are in charge of two profiles, 
you can end up with duplicates. (An example of this being the way XForms 
and XHTML2, which are done by a lot of the same people, has had clashes.)


> If it is defined that the resources referenced by the profile attribute 
> should be XMDP (which would be a big improvement over HTML4, which 
> leaves the format explicitly undefined), and UAs were able to download 
> the profile and determine its values, then that would solve a lot of 
> problems.

Agreed. That will probably happen at some point. (It's on my list.)


> > Changed "changes" to "introduces new definitions", which is what I 
> > meant. A profile should never drop values it previously defined, and 
> > this will be mentioned in the relevant spec when that gets defined.
> 
> A profile version should never introduce, drop or change values and 
> semantics. If values are added, changed, deprecated or removed, a new 
> version with a new URI should be publised.

I don't think that's workable. For example, it means every time you 
upgrade to a more recent profile, all the old UAs will stop rendering your 
page -- it doesn't have a workable backwards compatibility migration path.


> > The author can't always know when the profiles he's using will end up with
> > clashes in the future.
> 
> They can if profiles remain persistent and although persistence can never be
> guarenteed with 100% certainty, such changes are a small use case that's
> unlikely to occur.

The advantage you get out of this doesn't IMHO outweight the problems.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WA1] lang and xml:lang

[Lachlan Hunt]

Ian Hickson wrote:
On Sun, 17 Apr 2005, Lachlan Hunt wrote:
# If both the xml:lang attribute and the lang attribute are set, user
# agents must use the xml:lang attribute, and the lang attribute must be
# ignored for the purposes of determining the element's language.
Is that the case for both HTML and XHTML documents?
Yes.
So, if I have this HTML document
  
  
  HTML document
  This is an HTML, not an XML, document.
Considering that legacy HTML UAs won't know about the xml:lang 
attribute, and will only use lang, are you saying that a conforming Web 
Apps UA should treat the document as french?

It would make more sense if, in the case of both being set, lang was 
used for text/html documents and xml:lang for XML documents.
The only way you can set xml:lang in an HTML document is via the DOM
Now I'm confused.  If that's the case, then wouldn't the above example 
be treated as english, regardless of the xml:lang attribute in the source?

(in HTML, there are no namespaces).
Which is why xml:lang should be completely ignored, as an unknown 
attribute, in HTML.

I don't think it's worth having special requirements for something
that no-one is likely to ever do outside of obscure test cases.
I've seen people use lots of XML syntax in HTML documents, including 
xmlns and xml:lang attributes even in one that had an explicit HTML4 
DOCTYPE (though I can't remember where) and not just in MS Word 
generated rubbish.  The point is authors do a lot of silly things, and I 
thought UA behaviour needed to be well defined for as many use cases as 
possible.

However, in the case of only one being set but for the wrong MIME type 
(eg. xml:lang set for text/html document or lang for XML document), for 
error recovery, should UAs be allowed to fallback on it?
If xml:lang="" is set onin a text/html document, it'll be {html, 
'xml:lang'}, not {xml, 'lang'} which is what xml:lang really is.
I don't understand how that answers the question.
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] [WA1] The profile Attribute

[Lachlan Hunt]

Ian Hickson wrote:
On Sun, 17 Apr 2005, Lachlan Hunt wrote:
1. There are no reasons there to avoid multiple profiles all together,
  only reasons to avoid profiles with conflicting definitions.
Imagine you use publicly available profiles A and B.
A has definitions "foo" and "bar".
B has definitions "baz".
You use foo, bar, and baz extensively in your document.
Two months later, the author of profile A updates his profile to include 
the definition "baz", meaning something completely different to the 
definition from profile B.
Well, I'd say the author of profile A has broken some rules by not 
keeping the URI for an old version persistent.  Profile authors should 
(hopefully) be smarter than that.  Even when XFN was updated from 1.0 to 
1.1, a new URI was given to avoid altering the semantics of existing 
documents in any way.

I'd say the chances of the above occuring are slim, and not worth 
affecting the ability to make use of multiple profiles.  The spec could, 
instead, provide a strong recommendation for profile authors to keep 
profile versions persistent.

Your document has now radically changed meaning, yet you didn't use 
profiles that had clashing meanings when you wrote your document.
In which case, I'm sure many authors would be complaining to the profile 
author about such a change, and I still don't think the spec needs 
unnecessary restrictions for this small use case.

The only way I can see to avoid this is to use only one profile, since
then you can't ever get clashes.
There are other ways I've seen proposed, such as using namespaces:
http://www.protogenius.com/rel-schemas/draft-scheid-rel-schemas-00.htm
Although that proposal doesn't seem to even make use of the profile 
attribute, but rather link elements which would be a big improvment over 
the profile attribute.

Imagine you use publicly available profiles A and B.
A has definitions "foo" and "bar".
B has definitions "foo" and "baz".
...
Someone uses a browser that supports only profile B. Now your document 
will be rendered or processed with completely different semantics, because 
the UA thinks that by "foo" you mean B's "foo".

Your document has now radically changed meaning,
That's a valid use case to avoid profiles with conflicting definitions, 
not against multiple profiles in general.

3. That also forces unnecessary restrictions on which profiles a UA may
  support and process.  For example:
  * User Agent A implements XFN
  * User Agent B implements RelLicence
  * A document uses both XFN and RelLicence, and specifies XFN first
in the profile attribute.
...
That's a fair point, but implementing XFN for user agent B might be simply 
a matter of dereferencing the profile URI, downloading the XMDP 
description (or whatever we end up specifying should be at the end of 
profile URIs -- something will eventually be specified) and ignoring the 
values from that profile.
If it is defined that the resources referenced by the profile attribute 
should be XMDP (which would be a big improvement over HTML4, which 
leaves the format explicitly undefined), and UAs were able to download 
the profile and determine its values, then that would solve a lot of 
problems.

Changed "changes" to "introduces new definitions", which is what I meant. 
A profile should never drop values it previously defined, and this will be 
mentioned in the relevant spec when that gets defined.
A profile version should never introduce, drop or change values and 
semantics.  If values are added, changed, deprecated or removed, a new 
version with a new URI should be publised.

The author can't always know when the profiles he's using will end up with 
clashes in the future.
They can if profiles remain persistent and although persistence can 
never be guarenteed with 100% certainty, such changes are a small use 
case that's unlikely to occur.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] [WA1] lang and xml:lang

[Ian Hickson]

On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> 
> # If both the xml:lang attribute and the lang attribute are set, user
> # agents must use the xml:lang attribute, and the lang attribute must be
> # ignored for the purposes of determining the element's language.
> 
> Is that the case for both HTML and XHTML documents?

Yes.


> It would make more sense if, in the case of both being set, lang was 
> used for text/html documents and xml:lang for XML documents.

The only way you can set xml:lang in an HTML document is via the DOM (in 
HTML, there are no namespaces). I don't think it's worth having special 
requirements for something that no-one is likely to ever do outside of 
obscure test cases.


> However, in the case of only one being set but for the wrong MIME type 
> (eg. xml:lang set for text/html document or lang for XML document), for 
> error recovery, should UAs be allowed to fallback on it?

If xml:lang="" is set onin a text/html document, it'll be {html, 
'xml:lang'}, not {xml, 'lang'} which is what xml:lang really is.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WA1] lang and xml:lang

[Lachlan Hunt]

Ian Hickson wrote:
On Sun, 17 Apr 2005, Lachlan Hunt wrote:
It should be stated that lang is for HTML only and xml:lang is 
for X(HT)ML only.
Done.
Thank you, but now there's just one more issue.
# If both the xml:lang attribute and the lang attribute are set, user
# agents must use the xml:lang attribute, and the lang attribute must be
# ignored for the purposes of determining the element's language.
Is that the case for both HTML and XHTML documents?  It would make more 
sense if, in the case of both being set, lang was used for text/html 
documents and xml:lang for XML documents.

However, in the case of only one being set but for the wrong MIME type 
(eg. xml:lang set for text/html document or lang for XML document), for 
error recovery, should UAs be allowed to fallback on it?

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

Re: [whatwg] [WA1] The profile Attribute

[Ian Hickson]

On Sun, 17 Apr 2005, Lachlan Hunt wrote:
> 
> 1. There are no reasons there to avoid multiple profiles all together,
>only reasons to avoid profiles with conflicting definitions.

Imagine you use publicly available profiles A and B.

A has definitions "foo" and "bar".

B has definitions "baz".

You use foo, bar, and baz extensively in your document.

Two months later, the author of profile A updates his profile to include 
the definition "baz", meaning something completely different to the 
definition from profile B.

Your document has now radically changed meaning, yet you didn't use 
profiles that had clashing meanings when you wrote your document. The only 
way I can see to avoid this is to use only one profile, since then you 
can't ever get clashes.


> 2. Forcing a UA to ignore all profiles occuring after one they do not
>understand places an unnecessary burden on the author to specify
>profiles in the order in which they are most supported by the UAs.

Imagine you use publicly available profiles A and B.

A has definitions "foo" and "bar".

B has definitions "foo" and "baz".

The definitions of "foo" in the two profiles is very different, but 
that's ok, because you specify that you are using profiles A and B and so 
if you use "foo" then it is the meaning from "A" and you clearly aren't 
saying the "foo" from B.

You use foo, bar, and baz extensively in your document.

Someone uses a browser that supports only profile B. Now your document 
will be rendered or processed with completely different semantics, because 
the UA thinks that by "foo" you mean B's "foo".

Your document has now radically changed meaning, yet your document was 
unambiguous when you wrote it. The only way I can see to avoid this is to 
tell UAs to ignore any profiles after one that they couldn't understand, 
since it stops them from assigning meaning incorrectly.


> 3. That also forces unnecessary restrictions on which profiles a UA may
>support and process.  For example:
> 
>* User Agent A implements XFN
>* User Agent B implements RelLicence
>* A document uses both XFN and RelLicence, and specifies XFN first
>  in the profile attribute.
> 
>In that scenario, user agent B unfairly loses out on being able to
>apply the semantics of the RelLicence profile.  Considering that UAs
>A and B are likely to serve different purposes There may be little
>reason for one to implement the other profile, for anything other
>than as work around for this specification.
> 
>This also defeats the whole purpose of allowing multiple profiles

That's a fair point, but implementing XFN for user agent B might be simply 
a matter of dereferencing the profile URI, downloading the XMDP 
description (or whatever we end up specifying should be at the end of 
profile URIs -- something will eventually be specified) and ignoring the 
values from that profile.

So I don't think that's a blocker problem.


> 4. The Note about a profiles defintion changing over time, somehow only
>affecting documents with multiple profiles makes no sense.  If a
>document uses any profile and its definition changes, then the
>semantics of the document are going to change too.  It is certainly
>not a reason to avoid multiple profiles.

Changed "changes" to "introduces new definitions", which is what I meant. 
A profile should never drop values it previously defined, and this will be 
mentioned in the relevant spec when that gets defined.


> I recommend updating the spec to say the following points:
> * If two profiles define the same name, then the semantic is given by
>   the first known URI specified in the profile attribute.

That implies that the semantics of a document depend on the UA that 
prociess it, which is clearly silly: a document has semantics even in the 
absence of any UA. (It might not be much use, but it has defined 
semantics!)


> * UAs may ignore unknown profiles and continue to process any subsequent
>   profiles.

For the reasons given above, I think this would be unwise.


> * Authors should avoid multiple profiles with conflicting defintions,
>   because UAs may apply differing semantics, depending on the profiles
>   they do and do not know.

The author can't always know when the profiles he's using will end up with 
clashes in the future.


> Remove the note from the end of the section entirely (or rewrite it) 
> because the reason given does not match the recommendation to avoid 
> multiple profiles, which is confusing.

Updated the note.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] [WA1] lang and xml:lang

[Ian Hickson]

On Sun, 17 Apr 2005, Lachlan Hunt wrote:
>
> Web apps currently states [1]:
> # Authors should not use the lang attribute in XML documents. Authors
> # should instead use the xml:lang attribute.
> 
> Is there any reason for not making that "must not"?  The only reason 
> someone would ever have for using lang instead of xml:lang in XHTML is 
> when serving it as text/html, which is strictly forbidden in this 
> version.  It should be stated that lang is for HTML only and xml:lang is 
> for X(HT)ML only.

Done.

> I think the heading for the attribute defintion should be updated to include
> xml:lang as well.

Done.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] WA1 dl and dialog

[Ian Hickson]

On Sat, 16 Apr 2005, fantasai wrote:

> # The dl element introduces an association list consisting of zero or more
> # name-value groups...
> # Name-value groups may be terms and definitions, speakers and words, metadata
> # topics and values, or any other groups of name-value data.
> 
> I like the definition you give here, except for one thing:
> Despite the example given in HTML4, I think that speakers and words
> is stretching the name-value idea a bit too far. For scripted dialog,
> I think Tantek's suggestion is much better:
>   http://tantek.com/presentations/2005/03/elementsofxhtml/#slide20
> 
> So my suggestion is to remove that particular example from the spec.

Done.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'