[whatwg] [WA1] The profile Attribute

Mon Apr 18 06:06:37 PDT 2005

Lachlan Hunt wrote:

> James Graham wrote:
>
>> <head profile="http://example.com#foo">
>> <profile href="http://example.com#bar" title="bar" />
>> <link rel="comments" href="#comments" />
>> <link rel="license" href="license.html" profile="bar" />
>> </head>
>
>
> The problem with that method is that it doesn't allow values from 
> multiple profiles to be included within the same element.

Is that an actual problem in practice? With <link /> one can always add 
another link element pointing to the same resource. I suppose it's more 
of an issue for random elements and class (although I still think using 
class is suboptimal).

>   Whereas, a solution that adds namespaces more like the following, 
> but doesn't require their use to reference the values where it is not 
> ambiguous would be better.
>
> For example, three profiles are defined with each given a namespace 
> prefx and contain the listed values.
>
> Profile 1: foo http://example.org/foo
>   Values: a, b, c
> Profile 2: bar http://example.com/bar
>   Values: c, d
> Profile 3: baz http://example.net/baz
>   Values: d, e, f
>
> foo and bar both contain "c", bar and baz both contain "d".  Without a 
> namespace, the semantics from the first declared profile should be 
> used in such cases and it is not possible to make use of the other.  
> With a form of optional namespace, it should be possible to refer to 
> those values in the following ways:
>
> The following unambiguosly refers "a" in foo in both cases:
>   rel="a" OR rel="foo.a"
>
> Because "c" is defined in both foo and bar, these are equivalent 
> because foo is defined first
>   rel="c" OR rel="foo.c"
>
> With a namespace, "c" in bar, can also be unambiguosly referenced:
>   rel="bar.c"
>
> Similarly, the follwing can also be unambiguously referenced:
>   rel="b d baz.d e f"

Having namespaces only where conflicts occur strikes me as unwise - in 
general the author is unlikely to know what the complete range of values 
in a given spec is and it makes documents very fragile to addition of 
data from new profiles and to addition of values to existing profiles. 
It also makes view-source style learning hard because the namespace will 
be included (or not) in an apparently random fashion. That's actually 
one of the problems with XML namespaces - from a document like:

<root xmlns="#foo"
          xmlns:bar="#bar">
  <bar:fragment>
    <element />
  </bar:fragment>
</root>

doing a simple view-source (without having read the Namespaces in XML 
spec) doesn't make it obvious which namespace <element/> is in.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs