[
Lists Home |
Date Index |
Thread Index
]
- From: "Rick Jelliffe" <ricko@allette.com.au>
- To: <xml-dev@ic.ac.uk>
- Date: Wed, 9 Jun 1999 15:28:40 +1000
From: David Megginson <david@megginson.com>
>Rick Jelliffe writes:
>
> > If I have to change namespaces URIs to generate acceptable data for
> > different uses, then namespaces are not providing universal names
> > as they should.
> One can hardly
>claim in any fairness that this is a breakdown in Namespaces -- it's a
>business problem that (with any scheme) can be solved only by the
>long, laborious process of discussion, trial implementation, and
>standardization.
What has it has it got to do with business or discussions? Any
application
family (stylesheets, schemas, etc) which does not have a mechanism (like
the stylesheet PI) to allow plurality of alternate technologies
(like CSS, XSL, DSSSL) ties its names into a specific technology.
W3C needs to make it standard procedure to define PIs (in whatever
syntax) to allow this plurality. Everytime there is a major application
family with no accompanying mechanism, it subverts the intent
and use of namespaces. Instead of providing universal names, it
provides application-specific names.
Do you see the difference?
It is a matter of providing a level playing-field. Of course we
can reprocess a document at the server end and rename the namespace
URIs for every different application; of course we can use content
negotiation to use the namespace URI as a key to the specific
application we are using; of course we can have a PI at the client
that rewrites part of the DOM so that other applications can
get to use the data.
But it is an unnecessary complication: if we want open and
extensible documents, they shouldn't gratuitously make
it difficult to retarget the document for different applications.
Of course when we use a different stylesheet language we
may have to restructure the document for best use: but we
should only have to do that to reflect the nature of the specific
stylesheet language, not merely because we are allowing
an *alternative* language. It is inefficent and promotes
data capture, which is one of the reasons everyone wants
to escape proprietary syntaxes.
Data capture is when a data format gratuitously ties in
data to a particular (vendor's or consortium's) technology:
"embrace and extend" or "embrace and lock-out" are the
same. We users demand that application-specific markup
be cleanly partitioned in a documents; we want namespaces
to be equally accessible for every use.
> Exactly the same problem could occur with
>Architectural Forms or any other mechanism for naming or subtyping.
Without going into details about how much namespaces share with
architectural forms...yes: it is a basic fragility of namespaces
as currenly specified. It should not be solved ad hoc by discussion, but
a standard procedure to enable extensibility and plurality.
Namespaces are dead, not because they are wrong IMHO, but because
they can be killed and are being killed, and we can safely predict that
without a mechanism to prevent data capture in every public application
area, they will be killed again in the future. The reason why I excluded
literature in my initial post is that, with the Schema PIs, namespaces
have escaped death for rendering applications.
Rick Jelliffe
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|
