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

Liam did suggest this being a WG but to my knowledge requiring hypermedia to be part of the xml: namespace wasn't part of the plan.
So what I don't understand is this:

"Running code and all would help."
+1000
 
Why is putting hypermedia in its own namespace for now a blocker ?  
I understand why you think it belongs in xml:* but I don't understand at all why that is such a critical issue you don't think the project
worthwhile if it cant.


-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
www.marklogic.com



-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Friday, June 07, 2013 1:48 PM
To: David Lee
Cc: public-xmlhypermedia@w3.org
Subject: RE: Open systems / Freedom ( was RE: The Web as an Application)

David,

If I recall correctly it was Liam who suggested  creating a CG.  I am OK with shutting it down if it
can't proceed without prejudice.  I feel that the XML core wg may have made a mistake, based on perhaps incomplete evidence.  I don't feel it is disrespectful of the w3c to examine ideas which may appear disruptive or radical.  The xml namespace is not 'property', I think.

Finally, I want what is good for XML.  And being successful on the web would be good for XML, IMHO.

So I just wanted it to be clear what is being rejected, and to give that idea a fair shake.  Running code and all would help.

Regards,
Peter
________________________________________
From: David Lee [David.Lee@marklogic.com]
Sent: June 7, 2013 10:17 AM
To: Rushforth, Peter
Cc: public-xmlhypermedia@w3.org
Subject: RE: Open systems / Freedom ( was RE: The Web as an Application)

Here is my stance.
We are a W3C community group.  So we should attempt to abide by W3C policies/politics/specs.

The reference you gave explicitly says:


--------------
Namespace change policy

The XML Core Working Group reserves the right to bring additional names from this namespace into active use by providing definitions for them in new specifications or subsequent editions of existing specifications. The Working Group may also make modifications to the definitions of the names already in use, although such changes will not normally change the well-formedness or validity of existing documents or significantly change their meaning.
-----------------

So the only way anything is going to be added to the xml: namespace , and still honor this policy is through the XML Core WG.
Certainly we are free to propose changes or additions to the XML WG ("new specifications") , but they have said repeatedly in they past they don't accept your arguments for why these particular attributes need to be in the xml: namespace and closed the issue.
Since "they" (XML Core WG) reserve this right we should attempt to usurp it.

My opinion (as a volunteer not an official representative) is that it is not productive to persue changes to the xml namespace in this WG for the above reasons.   I also feel personally it is close to a lack of respect of the W3C to attempt to circumvent this particular policy *within* a W3C community group after we have been told multiple times its not going to be accepted.   The act of maintaning a W3C community group, with the explicit sponsorship (and yes , funding to an extend) of the W3C whos primary intent is to circumvent the authority of a core WG to me feels wrong.  It's  the kind of politics I dont want to play even if it is not strictly forbidden.


I appreciate comments from anyone else in this group.   I am not in charge, I am only here on request to offer my advise.
So far this discussion has only been between Peter and me.   If no one else adds any opinions then I would say the group is at an impass.
Peter, I encourage you to continue in this group and look for another volunteer (such as yourself) to be be the chair, but if you choose to leave and no one else adds any input then it is probably best just to close the group and persue this agenda in other avenues because so far I haven't seen any strong lead  except by peter.

Again, this is just my personal opinion.  I am not affiliated with the W3C in any formal capacity in this group.




-----------------------------------------------------------------------------
David Lee
Lead Engineer
MarkLogic Corporation
dlee@marklogic.com
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
www.marklogic.com



-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca]
Sent: Friday, June 07, 2013 9:47 AM
To: David Lee
Cc: public-xmlhypermedia@w3.org
Subject: 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 17:52:52 UTC