17620 - Change RDF root to Mozilla

Status: VERIFIED WONTFIX

(Core Graveyard :: RDF, defect, P3)

Description

[Ben Bucksch (:BenB)]

In XULs, there're lots of references to <URL:http://home.netscape.com/NC-rdf#xxx>.
They should be
<URL:http://www.mozilla.org/NC-rdf#xxx> or similar. I'm willing (at least at
the moment :-)) to change that, if
 there's an ultimate decision about the new scheme.

Does the host have any meaning (apart from being unique)? I suspect not, but if
yes, the infrastructure on mozilla.org must be working, too.


This is basically a global find/replace and looking, if something breaks,
right?

Comment 1

[chris hofmann]

lets do this in the early stages on a milestone., not durning m12
stabilzation.   let me know if you disagree..

Comment 2

[Mike Shaver (:shaver emeritus)]

dmose, are we going to get this for M13?  AFAIK, the root URI just has to be
unique, and is never deferenced, so the risk seems pretty low.

Might be nice to warn people at the beginning of a milestone, in mozilla-rdf, so
I won't squawk too loudly if it gets bumped to M14.  We really want it fixed for
beta, though.

Comment 3

[leger]

Per pdt, not an M13 stopper, can you please move to M14.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Moving to M14, as requested.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

This should be in for beta, because we're likely to see a larger number of folks
start programming to this API, and it'd be better not break them after beta.

Comment 6

[leger]

Putting on PDT- radar for beta1. Get a mozilla person to check in.  not a 
commercial beta stopper.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Actually, I'll be the person checking in and I don't need any particular PDT
help on this, but I still think this should be tracked as a commercial beta
stopper bug, since if commercial beta ships without this fix, it will break
anyone who writes to the commercial beta-1 API because that API will then have
to change post beta-1.

Resetting status whiteboard so that you'll see this comment.

Comment 8

[Robert John Churchill]

cc'ing Chris and myself.

This bug is sort of a subset of the work that needs to be done in bug # 12161.

Comment 9

[leger]

Putting on PDT- radar for beta1.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

Chris is trying to find out whether there are any folks interested in the doing
the work to migrate us to the Dublin core first (and if it then makes more sense
to wait for that to happen).

Comment 11

[Ben Bucksch (:BenB)]

Adjusting meta bug to API instead of chrome.

Comment 12

[Chris Waterson]

i'm not going to fix this.

Comment 13

[Ben Bucksch (:BenB)]

that doesn't mean it shouldn't be fixed. REOPEN, REASSIGN to
<[e-mail]>, HELPWANTED.

Comment 14

[Ben Bucksch (:BenB)]

/

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: script which may be usable to help make this happen

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

I've attached a script written by Roger B. Sidje <[e-mail]>, which 
could perhaps be used to do the netscape->mozilla change (since there's clearly 
insufficient time to revamp things for the dublin core before shipping).  Here 
are his comments about the script:

The best way to go about this is to have a blanket approval for
everything. Otherwise, it is not encouraging to be waiting for
those reviews that never seem to happen fast enough, especially
for external people.

If you can check-in without these reviews/approvals, then it
is not going to be too much time consuming for you at all.

The way the script works is that, when you first run the
script it goes over the tree and tells you all the lines where
replacements are going to be made (without actually making them).
Then, after quickly looking at the possible replacements in the
output, if you want to go ahead, you set $just_show_me = 0; and
$checkin = 1; and run the script again. The script will then 
process the files by bacth of 10 (or less if changing directory).
Then the script will again show you the replacements to be made
for the current batch, and prompt you to continue. If you answer
OK, the script does a cvs update of these files and prompt you
again, if you see that no conflicts are reported (i.e, nobody
has checked-in while the script was working on these files), then
you go ahead, and the script does the check-in. And the script
continues with the next batch, until it has walked the whole tree.

(If conflicts arise the short time when replacements are been
made--which is bad luck, you can skip that batch, take note the
files, and fix them later after the script has completed)

So, as you see, it is mostly a matter of hitting the
[Y]es key when the script is prompting you.

This is relatively fast. What is slow and annoying is
to wait for the reviews that never seem to happen.
---
RBS
PS: Attached is the script. To speed/skip things in your linux box,
you can change WIN32_D.OBJ in replace_all_files() to whatever
is the obj dir on your linux box:

        next if ($file =~ m|WIN32_D.OBJ|i); # Win32 specific ...

Comment 17

[Ben Bucksch (:BenB)]

So, does somebody volunteer? dmose? If not, I might try my luck. But only if
mozilla.org gives me a blank r=, a= for that change.

Comment 18

[Mike Shaver (:shaver emeritus)]

What do you mean by ``blanket r=/a=''?  Reviewing and approving changes that
haven't been seen seems to defeat the purpose of review and approval, no?

I think someone on this bug could review the changes en masse, though.

Comment 19

[Ben Bucksch (:BenB)]

> What do you mean by ``blanket r=/a=''?

"Yes, you can change all instances of "http://home.netscape.com/NC-rdf#" in the
tree to "http://www.mozilla.org/NC-rdf#""

Or what do you suggest?

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

I think a blanket a= would make sense, since that would simply signify that in
concept, it's the right change to make.  However, the point of r= is to get
folks visually proofreading the patches.  So people actually do need to look at
the changes you propose to checkin.

Comment 21

[Ben Bucksch (:BenB)]

How would I do that, technically? I thought, the script does everything
automatically? (Didn't try it out yet.)

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

Oh, you're right.  I guess my suggestion would be to comment out all the 
cvs-related stuff in the script.  Then run the script on a clean tree, build the 
tree to make sure things are ok, and then generate diffs for review using "cvs 
diff -u".

Comment 23

[Ben Bucksch (:BenB)]

brendan, can you give approval, please? The time between creating the diffs and
checkin should be as small as possible, and the change is pretty dumb, so please
approval beforehand.

Comment 24

[Chris Waterson]

This isn't the right change to be making. See discussion in bug 12161. If you
want to clean up the usage of RDF, then do it right.

Comment 25

[Ben Bucksch (:BenB)]

Waterson, I can't see discussion there. That's what's there I don't understand.
Also, it seems like a lot of work and is futured. But if we ship Netscape 6 or
Mozilla 1.0 with the current interfaces, we will have to maintain them forever.
I don't want that to happen. Comments?

Comment 26

[Ben Bucksch (:BenB)]

No comments. Fixing a problem half is better than not fixing anything. REOPENing.

BTW: Please don't mark rational bugs about Mozilla as INVALID just because you
disagree. Thank you.

Comment 27

[Ben Bucksch (:BenB)]

-> me.

Comment 28

[Ben Bucksch (:BenB)]

One more reason to fix this bug: All those "home.netscape.com" strings in the
source make it a lot hard to find all instances of hookups to netscape sites in
the Mozilla tree, which is a common task for rebranding.

Comment 29

[Ben Bucksch (:BenB)]

Getting schizophrenic: Moving all bugs for Beonex <http://www.beonex.com> to my
second Bugzilla identity <[e-mail]>.

Comment 30

[Ben Bucksch (:BenB)]

Am I allowed to fix this bug?

Comment 31

[Ben Bucksch (:BenB)]

ping.

Comment 32

[Gervase Markham [:gerv]]

Ben, it's too late for this. A few Netscape strings in the source (as opposed to
the UI) isn't going to hurt anyone.

Gerv

Comment 33

[Ben Bucksch (:BenB)]

Compare the trouble that has been caused by Netscape removing the RDF defintion
(used for news headlines) from its web server, because lots of software tried to
validate the documents.

Comment 34

[Ben Bucksch (:BenB)]

-> somebody else. (Dice points to dmose; reassign to somebody else or nobody, if
you don't want it.)

I still think that it should be fixed before 1.0.

Comment 35

[Dan Mosedale (:dmosedale, :dmose)]

Reassigning to nobody; this isn't something I have time to work on.

Comment 36

[Tony Tovar]

Any reason not to bump this to 1.01?  It sounds like it might have consequences,
i.e., destabilizing.

Comment 37

[Ben Bucksch (:BenB)]

This is an API-freeze thing.

Comment 38

[benc]

tever is not RDF QA anymore

Comment 39

[Axel Hecht]

Let's just get rid of this one.

Changing the name of a vocabulary doesn't make it sound or even documented. And
that is the fish we need to fry.

Comment 40

[Ben Bucksch (:BenB)]

verified dup of bug 12161