Closed Bug 17620 Opened 21 years ago Closed 15 years ago

Change RDF root to Mozilla


(Core Graveyard :: RDF, defect, P3)



(Not tracked)



(Reporter: BenB, Unassigned)



(Keywords: helpwanted, Whiteboard: [PDT-])


(1 file)

In XULs, there're lots of references to <URL:>.
They should be
<URL:> 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 must be working, too.

This is basically a global find/replace and looking, if something breaks,
Assignee: mozilla → dmose
Target Milestone: M12
Blocks: 14532
Target Milestone: M12 → M13
lets do this in the early stages on a milestone., not durning m12
stabilzation.   let me know if you disagree..
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.
Whiteboard: NOT M13 STOPPER
Per pdt, not an M13 stopper, can you please move to M14.
Whiteboard: NOT M13 STOPPER
Target Milestone: M13 → M14
Moving to M14, as requested.
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.
Keywords: beta1
Target Milestone: M14 → M15
Putting on PDT- radar for beta1. Get a mozilla person to check in.  not a 
commercial beta stopper.
Whiteboard: [PDT-]
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.

Whiteboard: [PDT-]
cc'ing Chris and myself.

This bug is sort of a subset of the work that needs to be done in bug # 12161.
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
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).
Assignee: dmose → waterson
Target Milestone: M15 → M20
Adjusting meta bug to API instead of chrome.
Blocks: 35548
No longer blocks: 14532
i'm not going to fix this.
Closed: 20 years ago
Resolution: --- → WONTFIX
that doesn't mean it shouldn't be fixed. REOPEN, REASSIGN to
Keywords: helpwanted
Resolution: WONTFIX → ---
Assignee: waterson → nobody
I've attached a script written by Roger B. Sidje <>, 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.
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 ...
So, does somebody volunteer? dmose? If not, I might try my luck. But only if gives me a blank r=, a= for that change.
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.
> What do you mean by ``blanket r=/a=''?

"Yes, you can change all instances of "" in the
tree to """

Or what do you suggest?
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.
How would I do that, technically? I thought, the script does everything
automatically? (Didn't try it out yet.)
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".
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.
Keywords: approval
Target Milestone: M20 → M18
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.
Closed: 20 years ago20 years ago
Resolution: --- → INVALID
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?
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.
Resolution: INVALID → ---
-> me.
Assignee: nobody → mozilla
Target Milestone: M18 → mozilla0.9.1
One more reason to fix this bug: All those "" 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.
Getting schizophrenic: Moving all bugs for Beonex <> to my
second Bugzilla identity <>.
Assignee: mozilla → ben.bucksch
Am I allowed to fix this bug?
Keywords: beta1nsbeta1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla1.0
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.

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.
-> 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.
Assignee: ben.bucksch → dmose
Keywords: mozilla1.0
Reassigning to nobody; this isn't something I have time to work on.
Assignee: dmose → nobody
Blocks: 104166
Any reason not to bump this to 1.01?  It sounds like it might have consequences,
i.e., destabilizing.
This is an API-freeze thing.
Keywords: mozilla1.1
Target Milestone: mozilla1.0 → ---
tever is not RDF QA anymore
QA Contact: tever → nobody
Blocks: 12161
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.
No longer blocks: 12161
Closed: 20 years ago15 years ago
Resolution: --- → WONTFIX
verified dup of bug 12161
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.