[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] RE: Namespace use cases
- From: Micah Dubinko <micah.dubinko@marklogic.com>
- To: rjelliffe@allette.com.au
- Date: Mon, 13 Jul 2009 18:26:43 -0700
This is a useful way to think about the use cases. Particularly in the
context of HTML:
#1 is critical. This falls under what the W3C calls "decentralized
extensibility", and is floating to the top of their awareness as a
problem.
#2 seems like it is probably important in some guise, but I'd like to
see more specific cases.
#3 may be a non-issue *for HTML*. One reason why this case gets less
attention is that is no consensus exists that using namespaces as a
major version number is a best practice (see, for example, the one
namespace vs three debates from another era of XHTML)
Like I mentioned, I'm interested in the HTML use cases based on recent
developments. One particular aspect is negative cases. For instance,
I'm pretty sure there are still people out there who think this was/
(is??) a requirement of xmlns:
* It must be possible for a document processor, upon encountering an
element in an unknown namespace, to locate a downloadable processor on
the web, in order to complete processing of the document.
Which is an unfortunate burden to bear. Thinking like this has led to
countless billions of uses of the string "http://www" in ugly
unmemorable namespace strings with very little resulting benefit, and
in fact a great deal of confusion. It's too late to fix this in XML,
but not too late for HTML.
So let's dig in to some usage details. Are there other parts of xmlns
that are over-engineered for use in HTML?
I'd like to see more examples too. What are some examples of
namespaces widely used in HTML? Are any of them from outside the W3C?
Thanks, -m
On Jul 11, 2009, at 3:06 AM, rjelliffe@allette.com.au wrote:
> I think there are three distinct cases.
>
#1
> The first is the declarations used for namespaces on elements and
> attribute names: the subject of the Namespaces in XML spec. This took
> multiple thousands of emails last time, so good luck on it this time.
>
#2
> The second is the namespaces used for Qnames in element and attribute
> values. XSLT went one way, but I think it is the wrong way because it
> fudges the difference between data and markup. Schematron has explicit
> elements and this has been very smooth: developers don't worry about
> default namespaces, they only need to look in a single place.
>
#3
> The third is that the role of namespace is challenged by emerging
> maintenance requirements. The generation of schemas developed without
> version attributes now face the challenge of how to cope when they
> need a
> major version upgrade, and namespaces are the obvious and (I think)
> correct thing to use as a slicker kind of major version number. (It
> is not
> that I am trying to say that namespace = schema, however namespace =
> major
> version = schema family or base schema is OK.)
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]