Open systems / Freedom ( was RE: The Web as an Application)

David,

> 
> If we want to make any progress I think we need first to 
> agree on a few things.
> If we cant agree on those I think no progress will be made.
> >> I argue that links between documents are as fundamental as 
> nesting of 
> >> elements and attributes, and so merit a place in the xml namespace
> 
> 
> I argue that pragmatically this is unimportant.
> I assert:
> This working group is not going to be able to add anything to 
> the xml: namespace.

Pragmatically, getting something added to this page:
http://www.w3.org/XML/1998/namespace
may not be possible in this lifetime.

However, the great thing about the Web, and thankfully about using
xml: in instance documents, is that there is no electronic
fence around it. 

A community is free to specify and develop, for example, an HTTP
header that doesn't appear in the HTTP RFC.  It doesn't break
anything, otherwise it would not have value.  HTTP has 'must ignore'
semantics, by design.  If the header proves popular and valuable,
it may eventually make its own RFC. 

THankfully, the smart people who invented
XML and namespaces left the xml namespace with 'must ignore'
semantics.

If a community came up with an extension to the xml namespace
that actually was useful and used, I'm pretty sure the xml core
wg would consider adding it 'officially', eventually.  
What's involved in doing that?
Not much beyond extending the page at the above address, that
I can tell.

I was having problems saving drafts yesterday, but did I mention
that it would be great to actually have a modified parser
that provided link support to applications.  I am really only
conversant in java, so a version of sax that supplied that
might be doable.  It could be interesting what use that could
be in xmlsh.

I am willing to discuss what the right approach is.  What is
'right' should be requirements-driven.  I don't see any way
around using the xml: namespace, given what I see as the 
requirements.

Number one: simplicity.  Simple enough for a tagger to remember
without reference to a syntax manual; simple enough for a
programmer to remember without reference to the media type
specification.  Simple enough that what gets typed in those
two scenarios 'just works'.  

Number two: backwards compatibility with the entire corpus
of xml documents and software.  Ie must be ignored if not understood.

Number three: minimum number features to support hypermedia, but no fewer.
If a feature is 'nice to have', but not necessary, it doesn't happen.
Not trying to reproduce xlink is a goal.  xlink exists, it may serve a
need for some.  Let them use it.
Conversely, if a feature is necessary, it should be in the spec.  

Granted these will generate debate.

> In order to do that we would need to be part of the XML 
> working group.  The XML spec clearly states that xml* 
> attributes, elements, and anything in the xml: namespace are 
> their domain.  Being part of W3C I dont think we can pull 
> that rug from them.
> 
> If we can't agree on this we can take it "upstairs" for 
> verification ... but I am fairly confident of this fact.

I am not interested in upstairs, actually.  In fact, you
are chair of this CG.  If what I'm saying is out of line
with what the community is seeking from your POV, it should be
me who departs.

> 
> if we can agree then lets proceed with the assumption that 
> this WG will propose a specification that does not include 
> changing the XML specification, lets proceed on that.

I've tried to articulate that I don't believe and up front
agreement on changing the xml spec is possible, so I guess
we agree.  

I personally don't see any value in even trying to come up
with a competing spec to xlink either, because that is as
unlikely to gain acceptance from the xml core wg  as 
changing xml spec by up front committee agreement is, too. 


Cheers,
Peter

Received on Friday, 7 June 2013 13:47:56 UTC